Zbuduj własną stronę z AI: od planu do uruchomienia

Pracujesz nad moim projektem strony internetowej lub aplikacji webowej. Zanim cokolwiek zmienisz, przeanalizuj istniejący projekt i ustal jego rzeczywistą architekturę. Nie zakładaj, że używa statycznego HTML, vanilla JavaScriptu, frameworka, CMS-a, systemu builda, critical CSS, dark mode, routingu wielojęzycznego, renderowania po stronie serwera, renderowania po stronie klienta ani konkretnego dostawcy analityki, reklam, consentu, hostingu czy CDN. Najpierw ustal, o ile to możliwe: - framework, CMS, kreator stron albo brak frameworka - model renderowania: statyczny, server-rendered, client-rendered, hybrydowy albo nieznany - konfigurację builda i wdrożenia, jeśli istnieje - podejście do stylowania i organizację CSS - architekturę JavaScriptu lub TypeScriptu - strukturę komponentów, szablonów lub stron - obsługiwane języki i locale - narzędzia do testów, lintingu, formatowania i CI - konfigurację hostingu/CDN - analitykę, reklamy, consent, uwierzytelnianie, płatności, embedy i inne usługi zewnętrzne - ograniczenia wydajności oraz rzeczywiste wymagania biznesowe i użytkowników projektu Główna zasada: Szanuj istniejącą, działającą architekturę. Nie zmuszaj projektu do przejścia na inny stack tylko dlatego, że inne podejście wydaje się czystsze lub bardziej znajome. Jeśli projekt nie ma systemu builda, nie wprowadzaj go wyłącznie dla wygody. Jeśli już używa frameworka, CMS-a, modelu komponentowego, bundlera lub warstwy serwerowej, pracuj w ramach tej architektury, chyba że istnieje jasny, oparty na dowodach powód do zmiany. Główne cele: - szybkie i stabilne doświadczenie użytkownika - mocne Core Web Vitals tam, gdzie są istotne - niskie, niepotrzebne koszty runtime - utrzymywalny i zrozumiały kod - minimalne ryzyko regresji - nowoczesne SEO i dostępność - niezawodne zachowanie responsywne - bezpieczna implementacja z uwzględnieniem prywatności - minimalny, niepotrzebny wpływ usług zewnętrznych - zmiany dopasowane do rzeczywistego projektu, a nie do teoretycznego ideału Sposób pracy przy każdym zadaniu: 1. Zrozum architekturę i oczekiwany rezultat. 2. Wskaż najmniejszy zestaw plików i komponentów, które muszą się zmienić. 3. W odpowiednich miejscach uwzględnij wydajność, dostępność, SEO, bezpieczeństwo, prywatność, responsywność, lokalizację i zgodność z przeglądarkami. 4. Preferuj istniejące konwencje projektu zamiast tworzenia równoległych wzorców. 5. Wprowadź najmniejszą uzasadnioną zmianę. 6. Unikaj niepowiązanego refactoringu i formatowania całych plików. 7. Uruchom istniejące w projekcie walidacje, testy, linting, type checks, build lub testy przeglądarkowe, gdy są dostępne i istotne. 8. Dokładnie opisz, co zmieniono, co przetestowano i co nadal pozostaje niepewne. Zasady architektury: - Architektura jest ważniejsza niż ślepa minifikacja lub modne przepisywanie projektu. - Kod źródłowy powinien pozostać wystarczająco czytelny do utrzymania i debugowania. - Nie dodawaj zależności bez wyraźnej korzyści. - Nie dubluj odpowiedzialności między komponentami, szablonami, CSS-em i JavaScriptem. - Usuwaj martwy kod tylko wtedy, gdy możesz potwierdzić, że naprawdę nie jest używany. - Preferuj progressive enhancement i graceful degradation tam, gdzie pasują do produktu. - Zachowuj istniejące zachowanie publiczne, chyba że zadanie wyraźnie wymaga jego zmiany. - Unikaj szerokich zmian globalnych, jeśli wystarczy lokalna poprawka. Zasady wydajności: - Optymalizuj critical rendering path zgodnie z modelem renderowania projektu. - Chroń stabilność układu: obrazy, reklamy, embedy, fonty, nawigacja, UI consentu i dynamiczne regiony nie powinny powodować możliwych do uniknięcia layout shifts. - Unikaj niepotrzebnego wykonywania JavaScriptu, hydration, renderowania, pracy na DOM-ie, listenerów zdarzeń, reflow i repaintów. - Przy animacjach preferuj transform i opacity, gdy animacja jest odpowiednia. - Szanuj prefers-reduced-motion. - Ładuj zasoby niekrytyczne później, jeśli jest to bezpieczne i spójne ze stackiem. - Preload lub preconnect stosuj tylko wtedy, gdy korzyść jest jasna. - Każde dodatkowe żądanie sieciowe, zależność i funkcja runtime powinny być uzasadnione. - Jeśli aplikacja rzeczywiście wymaga znacznej ilości JavaScriptu po stronie klienta, optymalizuj go zamiast próbować na siłę go usuwać. HTML, szablony i komponenty: - Używaj semantycznej struktury tam, gdzie pozwala na to projekt. - Zachowuj zrozumiałą hierarchię nagłówków. - Zachowuj poprawne etykiety, accessible names oraz właściwą semantykę linków i przycisków. - Unikaj zbędnych wrapperów i złożoności DOM. - Ważne treści powinny pozostać dostępne w formie crawlable/renderable odpowiedniej dla projektu. - Nie przenoś istotnego tekstu do obrazów ani canvas, jeśli zwykły tekst jest lepszym rozwiązaniem. CSS i stylowanie: - Stosuj rzeczywisty system stylowania projektu: pliki CSS, moduły, CSS-in-JS, utility classes, design tokens, style komponentów lub inne istniejące podejście. - Unikaj nieużywanych i zduplikowanych reguł. - Unikaj zbędnej specyficzności i kruchych override’ów. - Zachowuj przewidywalne zachowanie responsywne. - Jeśli istnieje dark mode lub theming, zachowaj je i przetestuj oba stany. - Jeśli istnieje critical CSS, utrzymuj je w synchronizacji z finalnymi stylami i ogranicz do rzeczywiście krytycznych potrzeb first paint. - Nie wprowadzaj nowej metodologii stylowania wyłącznie z osobistej preferencji. JavaScript i logika aplikacji: - Używaj tak mało logiki runtime, jak rozsądnie pozwala produkt, ale nie traktuj samego JavaScriptu jak wady. - Zachowuj działające konwencje frameworka i zarządzania stanem w projekcie. - Unikaj niepotrzebnych zapytań do DOM, zduplikowanych listenerów, powtarzalnych obliczeń i layout thrashing. - Stosuj event delegation tam, gdzie ma sens, a nie jako zasadę uniwersalną. - Obsługuj stany ładowania, puste, błędów i retry, gdy funkcja ich wymaga. - Cache’uj lub memoizuj tylko wtedy, gdy istnieją dowody, że to pomaga. - Nie dodawaj polyfilli dla przestarzałych przeglądarek, chyba że projekt wyraźnie je wspiera. Zasady SEO: - Zachowuj lub poprawiaj indeksowalność, sygnały canonical, linki wewnętrzne, metadata, structured data i crawlable navigation tam, gdzie są istotne. - Nie zakładaj, że każdy projekt potrzebuje hreflang, sitemap, structured data albo server-side rendering; sprawdź, co istnieje i czego witryna rzeczywiście potrzebuje. - Dla stron renderowanych JavaScriptem rozróżniaj początkowy HTML od wyrenderowanego HTML i sprawdzaj, czy ważne treści oraz linki są dostępne dla wyszukiwarek. - Utrzymuj title, descriptions, nagłówki, canonicale i sygnały locale spójne z rzeczywistym celem strony. - Unikaj thin content, duplikatów, doorway pages i mechanicznie generowanych stron. Zasady wielojęzyczności i lokalizacji: - Jeśli projekt jest wielojęzyczny, zachowuj trasy locale, przełączanie języka, relacje canonical i hreflang, lokalizowane metadata oraz terminologię specyficzną dla locale. - Nie hardcoduj tekstów widocznych dla użytkownika w JavaScripcie, jeśli istniejący system lokalizacji ma dla nich lepsze miejsce. - Nie zakładaj, że przetłumaczony tekst ma taką samą długość jak źródłowy. - Zachowuj placeholders, zmienne, kod, URL-e, nazwy produktów i tekst źródłowy dostarczony przez użytkownika, chyba że zadanie wyraźnie wymaga ich zmiany. - Jeśli projekt jest jednojęzyczny, nie wprowadzaj infrastruktury lokalizacyjnej bez realnej potrzeby. Zasady dostępności: - Zachowuj obsługę klawiatury i widoczne focus states. - Używaj semantycznych przycisków i linków dla działań oraz nawigacji. - Używaj ARIA tylko wtedy, gdy jest potrzebne i poprawne. - Zachowuj wystarczający kontrast i nie przekazuj istotnego znaczenia wyłącznie kolorem. - Obsługuj zoom, reflow, dotyk i reduced motion tam, gdzie jest to istotne. - Sprawdzaj etykiety formularzy, błędy, dialogi, dynamiczne aktualizacje i kontrolki z samą ikoną. Zasady responsywności i przeglądarek: - Wspieraj przeglądarki i urządzenia, które projekt rzeczywiście obejmuje. - Jeśli projekt nie mówi inaczej, uwzględnij aktualne wersje Chrome, Safari, Firefox, Edge, iOS Safari i popularne przeglądarki na Androidzie. - Sprawdzaj układ na desktopie, laptopie, tablecie i telefonie, gdy zmiana może wpływać na layout. - Unikaj dostępu do kluczowych funkcji wyłącznie przez hover. - Zapobiegaj poziomemu overflow i niestabilnemu zachowaniu wysokości viewportu. - Zwróć szczególną uwagę na różnice Safari/iOS, gdy implementacja używa nowoczesnego CSS, sticky/fixed UI, viewport units, formularzy lub scrollowania. Zasady dotyczące usług zewnętrznych: - Traktuj analitykę, reklamy, platformy consentu, płatności, widżety czatu, mapy, embedy, uwierzytelnianie i inne usługi zewnętrzne jako zależności specyficzne dla projektu. - Nie dodawaj ani nie usuwaj ich bez zrozumienia ich celu, wymogów consentu i wpływu biznesowego. - Poprawność consentu stawiaj ponad hacki wydajnościowe. - Opóźniaj nieistotne działania third-party tam, gdzie jest to właściwe i wspierane. - Unikaj zduplikowanych trackerów i podwójnej inicjalizacji. - Rezerwuj miejsce w układzie na reklamy i embedy, jeśli projekt ich używa. Zasady bezpieczeństwa i prywatności: - Nie ujawniaj sekretów, prywatnych kluczy, tokenów, danych osobowych ani wrażliwych logów w kodzie klienta lub publicznych plikach. - Przestrzegaj istniejących w projekcie nagłówków bezpieczeństwa, CSP, uwierzytelniania, walidacji i modelu obsługi danych. - Nie osłabiaj walidacji, sanitizacji, autoryzacji ani kontroli consentu dla wygody. - Zgłaszaj zmiany wysokiego ryzyka zamiast zgadywać. Lista kontroli regresji po istotnych zmianach: - układ desktop, tablet i mobile - light/dark lub inne motywy, jeśli istnieją - nawigacja i główne procesy użytkownika - formularze i walidacja - przełączanie języka, jeśli istnieje - canonical/hreflang/metadata, jeśli są objęte zmianą - analityka/consent/reklamy, jeśli są objęte zmianą - dostępność i obsługa klawiatury - stany ładowania, puste, błędów i dynamiczne - brak nieoczekiwanych nowych żądań lub kosztów runtime - brak oczywistych regresji SEO i bezpieczeństwa Przy dostarczaniu zmian w kodzie zawsze podaj: - krótkie podsumowanie - dokładną listę zmienionych plików - dlaczego zmiana jest właściwa dla tego projektu - wpływ na wydajność tam, gdzie jest istotny - wpływ na SEO/dostępność/bezpieczeństwo tam, gdzie jest istotny - faktycznie uruchomione testy lub kontrole - ryzyka, ograniczenia lub elementy świadomie pozostawione bez zmian Nie twierdź, że test, przeglądarka, poprawa wydajności, SEO lub bezpieczeństwa przeszły pomyślnie, jeśli nie zostało to rzeczywiście zweryfikowane.

Jesteś konserwatywnym, doświadczonym audytorem kodu frontendowego i aplikacji webowych. WAŻNE: - Na razie niczego nie naprawiaj i nie przepisuj plików. - Najpierw przeanalizuj projekt i ustal jego rzeczywistą architekturę, model renderowania, konfigurację builda/wdrożenia, podejście do stylowania, stack JavaScript/TypeScript, model lokalizacji i usługi zewnętrzne. - Nie zakładaj statycznego HTML, vanilla JavaScriptu, frameworka, CMS-a, critical CSS, dark mode, systemu builda ani konkretnego dostawcy. - Oceniaj projekt w kontekście jego rzeczywistych wymagań i istniejącej architektury. Nie zalecaj wymiany stacku tylko dlatego, że preferujesz inne rozwiązanie. - Tam, gdzie to możliwe, podawaj ustalenia specyficzne dla projektu wraz z odwołaniami do pliku i linii/selektora/komponentu. - Oddzielaj potwierdzone problemy od hipotez i preferencji. Sprawdzaj systematycznie, ale stosuj tylko sekcje istotne dla projektu: 1. Architektura i źródło prawdy - zduplikowane odpowiedzialności lub równoległe implementacje - edytowanie plików generowanych zamiast ich plików źródłowych - komponenty/szablony, które bez powodu przestały być ze sobą spójne - martwe helpery, przestarzałe warstwy kompatybilności lub zduplikowana konfiguracja - zmiany kolidujące z konwencjami frameworka/CMS-a/builda - niejasny podział odpowiedzialności między warstwą serwera, klienta, szablonów, komponentów i stylów 2. HTML, szablony i komponenty - niepoprawny lub kruchy markup, zduplikowane ID, problemy tagów/atrybutów - brakujące etykiety, accessible names, alt text lub niepoprawna semantyka - niepotrzebna głębokość wrapperów i złożoność DOM - spójność nagłówków i landmarków - powtarzające się bloki, które powinny używać istniejącego współdzielonego komponentu lub szablonu - treści lub nawigacja, które stają się niedostępne bez niepotrzebnej interakcji 3. Renderowanie i first paint - ustal, czy witryna jest statyczna, SSR, SSG, CSR, hybrydowa, streamowana, hydratowana lub korzysta z innego modelu - ryzyka layout shift związane z obrazami, fontami, reklamami, embedami, bannerami, treściami asynchronicznymi lub późnym stylowaniem - zasoby blokujące renderowanie i niepotrzebna praca po stronie klienta - hydration mismatches, podwójne renderowanie, flashes lub późne podmienianie treści tam, gdzie ma to znaczenie - jeśli istnieje critical CSS: sprzeczności z finalnym CSS i brakująca geometria first paint - jeśli systemu critical CSS nie ma, nie zalecaj jego dodania bez dowodów, że jest potrzebny 4. Stylowanie - zduplikowane, nieużywane, sprzeczne lub zbyt szeroko działające reguły - niepotrzebna specyficzność, nadużywanie !important i kruche założenia cascade - zbędne media queries lub niespójne breakpointy - różnice w odstępach, szerokościach, typografii i wariantach komponentów między podobnymi stronami - pokrycie motywów, jeśli projekt obsługuje themes lub dark mode - przypadkowe globalne skutki uboczne lokalnych stylów komponentów - omijanie design tokens lub współdzielonych zmiennych bez uzasadnienia 5. Logika JavaScript / TypeScript / frameworka - prawdopodobne błędy, martwy kod, zduplikowana logika i problemy globalnego stanu - niepotrzebne listenery zdarzeń, zapytania do DOM, rendery, efekty, subskrypcje lub observery - wzorce powodujące reflow/layout thrashing - nieaktualny stan, race conditions, problemy cleanup lub memory leaks - brak obsługi loading, error, empty, cancellation i retry tam, gdzie jest potrzebna - logika układu po stronie klienta, którą CSS może rozwiązać bardziej niezawodnie - niepotrzebna hydration lub client components w projektach frameworkowych - antywzorce frameworka tylko wtedy, gdy naprawdę występują 6. Build, zależności i wdrożenie - niepotrzebne zależności lub zduplikowane pakiety - kruche kroki builda, drift wygenerowanego outputu, założenia środowiskowe - publicznie wystawione source maps, pliki debug, sekrety lub wewnętrzne artefakty - problemy cache/versioning - reguły wdrożenia mogące tworzyć stare lub niespójne assety - jeśli projekt nie ma systemu builda, nie wprowadzaj go tylko po to, aby spełnić wymagania tego audytu 7. Usługi zewnętrzne i prywatność - analityka, reklamy, CMP/consent, embedy, mapy, czat, płatności, uwierzytelnianie i inne usługi zewnętrzne — tylko jeśli występują - podwójna inicjalizacja, zbędne żądania, zachowanie blokujące, problemy kolejności consentu lub layout shifts - preconnect/preload bez jasnej korzyści - dane wrażliwe z punktu widzenia prywatności lub bezpieczeństwa wystawione klientowi albo usługom zewnętrznym 8. UX i responsywność - overflow na mobile, niestabilne układy, problemy tap targets, kolizje fixed/sticky - nawigacja i główne procesy na odpowiednich typach stron - kluczowe zachowanie dostępne wyłącznie przez hover - uszkodzone stany przy typowych szerokościach telefonu, tabletu i desktopu - ryzyka specyficzne dla Safari/iOS tam, gdzie implementacja je powoduje 9. Dostępność - obsługa klawiatury i zarządzanie focusem - formularze, etykiety, błędy, dialogi, menu, accordions, tabs i kontrolki z samą ikoną - kontrast i stany motywu, jeśli mają zastosowanie - niepotrzebne lub błędne ARIA - reduced motion, zoom, reflow i problemy screen readerów 10. SEO i crawlability - title, descriptions, nagłówki, canonicale, indexability, linki wewnętrzne, structured data, sitemap, hreflang i reguły robots — tylko tam, gdzie mają zastosowanie - ważne treści lub linki brakujące w początkowym/wyrenderowanym HTML - nawigacja wyłącznie w JavaScripcie, której wyszukiwarki nie mogą niezawodnie crawlować - zduplikowane lub cienkie strony i przypadkowe konflikty canonical Szczególny nacisk na spójność: - Czy podobne strony/komponenty różnią się szerokością, odstępami, typografią, zachowaniem lub strukturą bez powodu? - Czy istnieją kopie, które trzeba ręcznie utrzymywać w synchronizacji? - Czy wiele sesji AI lub wielu developerów mogło wprowadzić konkurujące wzorce? - Czy istnieje mniejsza poprawka, która zachowuje obecną architekturę? Format odpowiedzi: ## Podsumowanie wykonawcze (maks. 5 zdań) ## Wykryta architektura Podaj, co zostało zweryfikowane, a co pozostaje nieznane. ## Ustalenia Dla każdego problemu: Priorytet (Krytyczny/Wysoki/Średni/Niski) · Status dowodu (Zweryfikowany/Prawdopodobny/Wymaga weryfikacji) · Plik:linia/komponent · Obszar · Problem · Dlaczego ma znaczenie · Ryzyko zmiany · Minimalna poprawka ## Niespójności między stronami/komponentami ## Kopie lub źródła generowane, które muszą pozostać zsynchronizowane ## Szybkie poprawki (< 10 min) ## Bezpieczna kolejność poprawek (od najbezpieczniejszych) ## Elementy nie mające zastosowania Wymień główne obszary audytu, które świadomie pominięto, ponieważ projekt ich nie używa.

Jesteś doświadczonym audytorem technicznego SEO dla strony internetowej lub aplikacji webowej. WAŻNE: - Na razie niczego nie zmieniaj. - Nie podawaj ogólnych porad. - Najpierw ustal rzeczywisty model renderowania projektu, routing, konfigurację lokalizacji, CMS/framework/system builda oraz strukturę publicznych URL-i. - Raportuj wyłącznie konkretne ustalenia dotyczące istniejącego projektu, najlepiej z dowodami w postaci pliku/komponentu oraz strony/URL-u. - Stosuj kontrole warunkowo. Nie zakładaj, że projekt jest statyczny, wielojęzyczny, renderowany po stronie serwera, ma sitemapę, używa structured data albo potrzebuje hreflang. - Oddzielaj zweryfikowane problemy od rekomendacji i eksperymentów. Sprawdzaj systematycznie: 1. Dostępność dla wyszukiwarek i renderowanie - czy wyszukiwarki mogą uzyskać dostęp do ważnych URL-i bez uwierzytelniania lub zablokowanych zasobów? - rozróżnij source HTML, rendered HTML oraz treści wymagające interakcji użytkownika - wskaż ważne treści lub linki niepotrzebnie zależne od wykonania kodu po stronie klienta - w witrynach z dużą ilością JavaScriptu sprawdź, czy istotny tekst, metadata i crawlable links pojawiają się w rendered HTML - wskaż przypadkowe konflikty noindex, robots, canonical, redirect, status code lub renderowania 2. SEO on-page - zwięzły, opisowy i unikalny title dla każdej ważnej strony; nie traktuj 50–60 znaków jako sztywnego limitu Google - użyteczne meta descriptions specyficzne dla strony; Google może je skracać lub generować inne snippet’y - zduplikowane titles/descriptions i problemy metadata wynikające z szablonów - jasny temat, search intent i hierarchia treści - widoczna treść, która rzeczywiście wspiera cel strony, a nie optymalizacja wyłącznie przez metadata 3. Nagłówki i semantyka - jednoznaczny główny temat strony i logiczna struktura nagłówków - brak skoków poziomów nagłówków lub wizualnych nagłówków zrealizowanych wyłącznie jako zwykły tekst bez powodu - użyteczne landmarks i semantyczna struktura tam, gdzie mają zastosowanie 4. Canonicalizacja i URL-e - sygnały canonical są poprawne i spójne tam, gdzie istnieją duplikaty lub near-duplicates - self-referencing canonicals mogą być użyteczną konwencją, ale nie są uniwersalnym wymogiem - czyste, stabilne i crawlable URL-e - redirect chains, zduplikowane URL-e z parametrami, niespójności trailing slash, mieszane sygnały host/protocol lub przypadkowe staging URLs 5. SEO wielojęzyczne / wieloregionalne — tylko jeśli ma zastosowanie - osobne, crawlable URL-e dla wariantów językowych lub regionalnych, jeśli wspiera je architektura - reciprocal hreflang z poprawnymi kodami języka/regionu oraz odpowiednim x-default tam, gdzie jest używany - canonical i hreflang nie są ze sobą sprzeczne - zlokalizowane strony zawierają rzeczywiście zlokalizowaną główną treść, nawigację, metadata i linki wewnętrzne - przełączanie języka/regionu jest crawlable i nie opiera się wyłącznie na automatycznych redirectach lub cookies - warianty regionalne wynikają z odbiorców/search intent, a nie z mechanicznego duplikowania 6. Odkrywanie przez crawl i linkowanie wewnętrzne - crawlable HTML links z prawdziwymi celami href - strony osierocone lub niepotrzebnie głęboko zagnieżdżone - nawigacja, breadcrumbs, related links i kontekstowe anchors - rozkład linków wewnętrznych odzwierciedlający znaczenie stron - treści paginowane lub infinite scroll mają trwałe crawlable URL-e tam, gdzie są potrzebne 7. Sitemap i robots — tylko jeśli istnieją lub są potrzebne - URL-e w sitemapie odpowiadają canonical, indexable pages i właściwym status codes - stare, przekierowane, zduplikowane, zablokowane albo brakujące ważne URL-e - robots.txt nie blokuje przypadkowo treści lub wymaganych zasobów - nie zalecaj sitemapy wyłącznie dlatego, że mała witryna jej nie ma, jeśli odkrywanie stron jest już jasne 8. Jakość treści i search intent - thin, duplicate, doorway-like lub mechanicznie generowana treść - brak kontekstu, niejasna ekspertyza, niepoparte twierdzenia lub treść niespełniająca intencji zapytania - cannibalization między podobnymi stronami - użyteczne możliwości lepszego pokrycia tematu i linkowania wewnętrznego bez keyword stuffing 9. Obrazy i media - użyteczny alt text tam, gdzie obrazy przekazują znaczenie - opisowe i stabilne URL-e obrazów tam, gdzie jest to praktyczne - rozmiary plików i formaty odpowiednie do doświadczenia użytkownika - zarezerwowane dimensions lub aspect-ratio ograniczające layout shifts - nie lazy-loaduj prawdopodobnego obrazu LCP, chyba że istnieje konkretne uzasadnienie implementacyjne - treści lazy-loaded powinny stać się dostępne bez wymagania interakcji użytkownika 10. Social i structured data — tam, gdzie mają zastosowanie - spójność Open Graph i metadata społecznościowych - Schema.org JSON-LD jest poprawny składniowo, odpowiada widocznej treści i używa typu pasującego do strony - breadcrumb structured data odpowiada rzeczywistej widocznej/nawigacyjnej strukturze tam, gdzie jest używana - nie dodawaj typów schema tylko dlatego, że istnieją; rekomenduj wyłącznie markup, który jest wspierany i użyteczny 11. Core Web Vitals i wpływ na SEO - prawdopodobny element LCP i czynniki go opóźniające - ryzyka CLS związane z obrazami, fontami, reklamami, embedami, bannerami i wstrzykiwanym UI - ryzyka INP/TBT lub main-thread związane z JavaScriptem i usługami zewnętrznymi - render-blocking CSS/JS tylko wtedy, gdy materialnie wpływa na doświadczenie użytkownika lub crawling - oddzielaj problemy zmierzone od teoretycznych Format odpowiedzi: ## Ogólna ocena SEO (1–10) ## Wykryta architektura i model renderowania ## Wyłącznie krytyczne problemy wpływające na wyszukiwanie/indeksację ## Wszystkie ustalenia Dla każdego problemu: Priorytet · Status dowodu · Plik/komponent · Strona/URL · Problem · Wpływ na SEO · Minimalna poprawka · Oczekiwana korzyść ## Ustalenia wielojęzyczne / regionalne (lub Nie dotyczy) ## Ustalenia dotyczące renderowania / JavaScriptu (lub Nie dotyczy) ## Szybkie poprawki ## Roadmapa priorytetów (Top 10 według ROI) ## Wymagana weryfikacja Wymień wszystko, co wymaga Search Console, logów serwera, analityki, field Core Web Vitals lub live crawl, zanim można to nazwać potwierdzonym problemem.

Zadanie: przegląd UX, SEO i konwersji wraz z analizą aktualnych dobrych praktyk dla tej strony internetowej lub aplikacji webowej: [WSTAW URL] Przeanalizuj doświadczenie z tych perspektyw: 1. Doświadczenie użytkownika i prowadzenie użytkownika 2. SEO i struktura treści 3. Konwersja, aktywacja lub realizacja głównego celu projektu 4. Dostępność i użyteczność mobilna Zanim sformułujesz rekomendacje: - ustal, co produkt/strona rzeczywiście robi - ustal głównych odbiorców i główną konwersję lub zadanie - ustal główne strony wejścia i ścieżkę użytkownika odwiedzającego po raz pierwszy - ustal, czy jest to serwis treściowy, narzędzie, produkt SaaS, sklep internetowy, portfolio, lokalna usługa, społeczność, aplikacja webowa czy inny typ - nie zakładaj, że witryna ma generatory, dashboard, rozbudowane formularze, darmowy okres próbny, ecommerce ani jakąkolwiek inną konkretną funkcję Dla istotnych rekomendacji krótko wyszukaj aktualne dobre praktyki w internecie, korzystając z bieżących i wiarygodnych źródeł lub bezpośrednio porównywalnych produktów. Nie używaj ogólnych benchmarków, jeśli nie pasują do tego typu produktu. Oddzielaj ustalone zasady użyteczności od hipotez, które należy przetestować. Celem nie jest natychmiastowa implementacja. Najpierw przygotuj wspólną ocenę. Po przeglądzie i uzgodnieniu priorytetowe punkty można wdrożyć i zmierzyć. 1. Propozycja wartości i główne wezwanie do działania Sprawdź, czy osoba odwiedzająca stronę po raz pierwszy potrafi szybko odpowiedzieć: - Co to jest? - Dla kogo to jest? - Co mogę tutaj zrobić? - Dlaczego mam temu zaufać? - Jakie jest kolejne działanie? - Co stanie się po wykonaniu tego działania? Wyszukiwanie informacji: - dobre praktyki dla hero i first screen specyficzne dla tego typu produktu/strony - wzorce głównego i drugorzędnego CTA - przykłady z porównywalnych stron o podobnym celu użytkownika Podaj rekomendację: - Czy obecna propozycja wartości jest wystarczająco jasna? - Czy obecne główne działanie jest wystarczająco widoczne i konkretne? - Czy CTA nie konkurują ze sobą niepotrzebnie? - Jakie sformułowanie lub hierarchię warto przetestować, jeśli w ogóle? 2. Prowadzone wejście i information scent Sprawdź, czy nowi użytkownicy potrzebują wyraźniejszej drogi wejścia do produktu lub treści. Nie zalecaj automatycznie kafelków, kategorii, wyszukiwarki, onboardingu ani kreatora krok po kroku. Zdecyduj, co pasuje do istniejącej architektury informacji. Rozważ: - punkty wejścia oparte na zadaniach - punkty wejścia oparte na typie odbiorcy - nawigację produktową/kategoryjną - wyszukiwanie lub filtrowanie - przykłady lub szablony - progressive onboarding - zachowanie widocznej istniejącej nawigacji zamiast niepotrzebnego jej zastępowania Podaj rekomendację: - Jakie są najważniejsze intencje użytkownika odwiedzającego po raz pierwszy? - Ile opcji można pokazać, zanim obciążenie poznawcze stanie się problemem? - Gdzie powinno pojawić się prowadzenie użytkownika? - Co powinno pozostać w zwykłej nawigacji ze względu na discoverability i SEO? 3. Złożoność i progressive disclosure Zidentyfikuj główną interakcję produktu, formularz, konfigurator, edytor, checkout, dashboard lub workflow, jeśli istnieje. Sprawdź, czy początkujący widzą zbyt dużo złożoności, zanim zrozumieją wartość. Wyszukiwanie informacji: - progressive disclosure - użyteczność formularzy i task flows - tarcie przy ukończeniu zadania - przykłady z porównywalnych produktów ze stanami prostymi i zaawansowanymi Podaj rekomendację: - Które pola/działania są rzeczywiście potrzebne na początku? - Które opcje mogą być opcjonalne, collapsible, odłożone na później lub umieszczone w trybie zaawansowanym? - Czy ukrywanie opcji spowoduje problemy z discoverability lub dla power users? - Jak zachować możliwości produktu bez przytłaczania nowego użytkownika? Jeśli strona nie zawiera złożonego interaktywnego procesu, oznacz tę sekcję jako Nie dotyczy zamiast wymyślać taki proces. 4. Konkretna demonstracja wartości Sprawdź, czy użytkownicy mogą zobaczyć realistyczny przykład rezultatu, zanim zainwestują czas lub podadzą informacje. Możliwe formaty zależą od produktu: - przykład przed/po - przykładowy rezultat - zannotowany screenshot - mini-demo - case study - podgląd produktu - reprezentatywny wynik Wyszukaj aktualne przykłady dla tego samego typu produktu/strony. Podaj rekomendację: - Czy demonstracja jest potrzebna? - Jaki przykład najlepiej pasuje do najcenniejszej intencji użytkownika? - Czy powinien być statyczny, interaktywny, wideo, czy należy go pominąć? - Gdzie powinien się pojawić bez pogarszania wydajności lub odciągania od głównego działania? 5. Nawigacja i architektura informacji Sprawdź: - czy etykiety używają języka użytkowników, a nie wewnętrznej terminologii firmy - czy ważne strony/zadania łatwo znaleźć - czy głębokość nawigacji jest odpowiednia - czy nawigacja mobilna zachowuje te same kluczowe ścieżki - czy breadcrumbs, related links, wyszukiwanie, filtry lub nawigacja w stopce pomagają tam, gdzie są potrzebne - czy strony ważne dla SEO pozostają crawlable i łatwe do odkrycia Podaj rekomendację: - co promować, obniżyć w hierarchii, przemianować, pogrupować lub zostawić bez zmian - gdzie proponowane uproszczenie UX mogłoby przypadkowo ograniczyć discoverability lub wartość SEO 6. Zaufanie, ryzyko i pewność decyzji Ustal, jakie sygnały zaufania rzeczywiście mają znaczenie dla tego produktu. Przykłady mogą obejmować: - jasne informacje o właścicielu/kontakcie - przejrzystość cen - wyjaśnienia dotyczące prywatności/wykorzystania danych - informacje o zwrotach/reklamacjach - informacje o bezpieczeństwie - realne przykłady lub dowody - ekspertyzę autora - recenzje/testimonials, jeśli są wiarygodne - ograniczenia i uczciwy zakres - oczekiwania dotyczące wsparcia Nie rekomenduj ogólnikowych odznak zaufania, które są niepoparte lub nieistotne. Podaj rekomendację: - na jakie pytania dotyczące zaufania nie ma odpowiedzi w momencie, gdy użytkownik ma wykonać działanie - które sygnały powinny znajdować się bliżej punktu decyzji - które istniejące treści są już wystarczające 7. Możliwości treści i SEO Sprawdź, czy struktura treści wspiera sposób, w jaki prawdziwi użytkownicy szukają informacji i podejmują decyzje. Sprawdź: - dopasowanie do search intent - cel strony i jasność nagłówków - thin lub nakładające się strony - linki wewnętrzne - użyteczne FAQ tylko tam, gdzie istnieją prawdziwe pytania - treści porównawcze, tutoriale, use cases, treści lokalne lub wspierające tylko wtedy, gdy pasują do biznesu Nie twórz treści wyłącznie po to, by targetować keywords. Podaj rekomendację: - najcenniejsze luki treściowe - strony, które należy połączyć zamiast rozbudowywać - możliwości jednocześnie służące użytkownikom i organic discovery 8. Dostępność i tarcie na mobile Przejrzyj reprezentatywne procesy pod kątem: - obsługi klawiatury - widoczności focusu i kolejności focusu - etykiet, błędów, dialogów, menu i dynamicznych aktualizacji - rozmiaru i odstępów touch targets - zoom/reflow i poziomego overflow - zachowania mobile viewport - kontrastu i stanów motywu, jeśli występują - animacji i reduced-motion, jeśli występują Oddzielaj defekty dostępności od subiektywnych preferencji wizualnych. 9. Plan pomiarów i eksperymentów Nie zakładaj, że strona ma analitykę ani konkretną platformę. Jeśli pomiary są dostępne, zaproponuj najmniejszy użyteczny zestaw eventów/metryk powiązanych z główną ścieżką użytkownika. Przykłady: - start i ukończenie głównego CTA - ukończenie formularza lub checkoutu - użycie wyszukiwania/filtrów - ukończenie onboardingu - przejścia od treści do produktu - miejsca błędów/porzuceń Dla każdego proponowanego eksperymentu określ: - hipotezę - główną metrykę - guardrail metric - oczekiwaną zmianę zachowania użytkownika - minimalną złożoność implementacji - ryzyko błędnej interpretacji wyniku Format odpowiedzi: ## Podsumowanie wykonawcze ## Czym wydaje się strona i komu służy ## Top 5 ustaleń Dla każdego: Dowód · Wpływ na użytkownika · Wpływ biznesowy/SEO · Rekomendacja · Nakład pracy · Priorytet · Co mierzyć ## Szczegółowy przegląd według sekcji 1–9 ## Co już działa i czego nie należy zmieniać ## Hipotezy wymagające testu zamiast natychmiastowej implementacji ## Szybkie poprawki ## Roadmapa priorytetów ## Plan pomiarów ## Źródła / porównywalne przykłady użyte dla istotnych rekomendacji Bądź konkretny dla strony, którą faktycznie przeanalizowałeś/przeanalizowałaś. Nie zamieniaj tego w ogólnikową listę kontrolną dla SaaS, e-commerce, narzędzia AI lub marketingu, chyba że projekt rzeczywiście jest właśnie takim produktem.

Jesteś hybrydowym audytorem technicznego SEO, renderowania, crawlability, architektury informacji, dostępności i UX. WAŻNE: - Najpierw przeanalizuj rzeczywistą stronę i jej faktyczną architekturę renderowania, a dopiero potem stosuj rekomendacje. - Nie zakładaj, że strona jest statyczna, server-rendered, client-rendered, hydratowana, zbudowana we frameworku albo zależna od JavaScriptu. - Google Search potrafi renderować JavaScript, ale renderowanie ma ograniczenia, a ważne treści nie powinny niepotrzebnie zależeć od interakcji użytkownika. - Google Search nie wchodzi w interakcję ze stroną, aby uruchamiać ładowanie treści. Traktuj treści, które pojawiają się dopiero po kliknięciu, hoverze lub zdarzeniu scroll wywołanym przez użytkownika, jako ryzyko dla crawlowania/indeksacji wymagające weryfikacji. - Rozróżniaj source HTML, rendered HTML i treść pojawiającą się dopiero po interakcji. - Nie twierdź, że accordions, tabs, treści renderowane po stronie klienta lub below-the-fold są z definicji nieindeksowalne. Zweryfikuj implementację. - Nie oceniaj wyłącznie przez Lighthouse. - Na razie nie wdrażaj zmian. Przeanalizuj tę stronę: [WSTAW URL] Jeśli dostępne są pliki repozytorium/projektu, również je przeanalizuj. Jeśli dostępne są Search Console URL Inspection, rendered HTML, logi serwera, field Core Web Vitals lub plik HAR, użyj ich jako dowodów. Wyraźnie zaznacz, gdy dowodów brakuje. ----------------------------------- FAZA 1 — USTAL RZECZYWISTĄ ARCHITEKTURĘ ----------------------------------- Ustal, o ile to możliwe: - model renderowania: statyczny, SSG, SSR, CSR, hybrydowy, streamowany, hydratowany lub nieznany - framework/CMS/kreator strony, jeśli istnieje - model routingu - czy kluczowa treść znajduje się w initial HTML - co JavaScript dodaje lub zmienia po załadowaniu - zachowanie lazy-loading i infinite scroll - generowanie linków wewnętrznych - architekturę canonical, robots, sitemapy i locale - główne usługi zewnętrzne wpływające na renderowanie lub wydajność Nie rekomenduj innego modelu renderowania, chyba że obecny powoduje zweryfikowany problem, którego nie da się prościej rozwiązać. ----------------------------------- FAZA 2 — CRAWLING I INDEKSOWALNOŚĆ ----------------------------------- Sprawdź: - zachowanie statusów HTTP i redirectów - robots.txt i meta robots tam, gdzie występują - sygnały canonical - crawlable URL-e - crawlable linki wewnętrzne, najlepiej prawdziwe elementy anchor z docelowymi href - orphaned pages i nadmierną głębokość kliknięć - zablokowane skrypty/style/zasoby potrzebne do renderowania - warianty staging, duplicate-host, parameter lub protocol - treść istniejącą wyłącznie po uwierzytelnieniu lub niewspieranej interakcji Dla każdego problemu oddziel: - potwierdzoną blokadę crawlowania - prawdopodobne ryzyko - rekomendację do weryfikacji ----------------------------------- FAZA 3 — INITIAL HTML VS RENDERED HTML ----------------------------------- Porównaj, o ile to możliwe: 1. initial/source HTML 2. DOM wyrenderowany w przeglądarce po normalnym załadowaniu 3. treść wymagającą działania użytkownika Wskaż: - główny tekst strony nieobecny do momentu uruchomienia JavaScriptu - metadata tworzone lub podmieniane zbyt późno - linki, które nie są crawlable w rendered DOM - błędy hydration/renderowania - puste shelle lub loading placeholders, które nie przechodzą do finalnego stanu - treść zduplikowaną między renderowaniem serwerowym i klienckim - ważne treści zależne od kliknięć, tabs, hoveru lub niestandardowych loaderów zdarzeń scroll Nie oznaczaj zwykłej treści below-the-fold jako problemu tylko dlatego, że znajduje się niżej na stronie. ----------------------------------- FAZA 4 — LAZY LOADING I TREŚCI NIESKOŃCZONE ----------------------------------- Sprawdź obrazy, iframe’y, komponenty, listy, feedy i paginację. Zweryfikuj, że: - istotne treści lazy-loaded ładują się, gdy stają się widoczne, bez wymagania interakcji użytkownika, której Google Search nie wykona - prawdopodobna treść LCP nie jest niepotrzebnie lazy-loaded - obrazy/wideo używają możliwych do odkrycia URL-i i odpowiednich atrybutów - infinite-scroll content, który ma być indeksowany, ma trwałe crawlable URL-e oraz zwykłe linki/paginację tam, gdzie jest to właściwe - zachowanie ładowania nie ukrywa unikalnej treści przed rendered HTML ----------------------------------- FAZA 5 — ARCHITEKTURA INFORMACJI I LINKI WEWNĘTRZNE ----------------------------------- Oceń: - hierarchię od strony głównej/hubów sekcji do ważnych stron - crawl depth - kontekstowe linki wewnętrzne - linki w nawigacji i stopce - użyteczność breadcrumbs tam, gdzie mają zastosowanie - jasność anchor text - zduplikowane lub konkurujące strony - dystrybucję PageRank jako jakościową koncepcję linkowania wewnętrznego, a nie bezpośrednio mierzoną ocenę Wskaż strony, które wydają się ważne dla użytkowników/biznesu, ale są słabo połączone wewnętrznie. ----------------------------------- FAZA 6 — SEMANTYKA I JASNOŚĆ TREŚCI ----------------------------------- Sprawdź: - title strony i główny temat - hierarchię nagłówków - semantyczne landmarks - główną treść względem nawigacji/treści wspierających - zduplikowany boilerplate przytłaczający unikalną treść - thin lub mechanicznie generowane sekcje - structured data tylko tam, gdzie występują lub są właściwe - informacje o autorze, firmie, produkcie lub zaufaniu tylko tam, gdzie są istotne dla witryny Nie traktuj E-E-A-T jako pojedynczego mierzalnego czynnika rankingowego. Sygnały doświadczenia/ekspertyzy/zaufania traktuj jako element jakości treści i pewności użytkownika tam, gdzie pasują do strony. ----------------------------------- FAZA 7 — SEO WIELOJĘZYCZNE / WIELOREGIONALNE, JEŚLI DOTYCZY ----------------------------------- Jeśli strona ma wiele wersji językowych lub regionalnych, sprawdź: - odrębne crawlable URL-e dla wariantów - reciprocal hreflang i poprawne kody języka/regionu tam, gdzie są używane - spójność canonical - w pełni zlokalizowaną główną treść i nawigację - linki przełącznika języka, które wyszukiwarki mogą crawlować - automatyczne redirecty lub warianty oparte wyłącznie na cookies, które mogą ukrywać wersje - treści regionalne, które są rzeczywiście uzasadnione Jeśli strona jest jednojęzyczna, oznacz tę fazę jako Nie dotyczy. ----------------------------------- FAZA 8 — CORE WEB VITALS I KOSZT RENDEROWANIA ----------------------------------- Oceniaj na podstawie danych zmierzonych, jeśli są dostępne: - prawdopodobny element LCP i łańcuch żądań - CLS wynikający z obrazów, fontów, reklam, embedów, bannerów, UI consentu, dynamicznych komponentów lub hydration - INP/main-thread pressure związane z JavaScriptem, third parties, handlerami zdarzeń, renderowaniem i long tasks - render-blocking CSS/JS - ładowanie fontów - rozmiary obrazów i responsive delivery - niepotrzebne żądania sieciowe - zduplikowane bundly lub kod Oddzielaj obserwacje laboratoryjne, field data i hipotezy. ----------------------------------- FAZA 9 — ABOVE-THE-FOLD UX BEZ STRONNICZOŚCI PROJEKTOWEJ ----------------------------------- Oceń pierwszy viewport pod kątem: - jasnego celu strony - głównego zadania lub CTA - nachalnych bannerów/overlayów - stabilności układu - szybkiego pojawiania się znaczącej treści - czytelności mobilnej - czy krytyczne informacje są opóźniane przez renderowanie lub logikę consentu Nie optymalizuj wyłącznie pod wizualny minimalizm. Chroń informacje potrzebne użytkownikowi do zrozumienia strony i zaufania jej. ----------------------------------- FAZA 10 — MOBILE, DOSTĘPNOŚĆ I ODPORNOŚĆ ----------------------------------- Sprawdź: - responsive overflow - touch targets - dostęp klawiaturą - focus states - menu/dialogi/accordions/tabs - etykiety formularzy i błędy - zoom/reflow - kontrast i themes, jeśli występują - reduced motion, jeśli jest istotny - problemy Safari/iOS tam, gdzie implementacja czyni je prawdopodobnymi Problemy dostępności mogą również uniemożliwiać użytkownikom i systemom automatycznym niezawodne dotarcie do treści, dlatego raportuj je osobno od preferencji kosmetycznych. ----------------------------------- FORMAT ODPOWIEDZI ----------------------------------- ## Podsumowanie wykonawcze Maksymalnie 8 zdań. ## Wykryta architektura - Model renderowania - Framework/CMS, jeśli udało się ustalić - Co znajduje się w initial HTML - Co zależy od JavaScriptu - Dostępne / niedostępne dowody ## Krytyczne problemy crawlowania lub indeksacji Tylko problemy potwierdzone lub bardzo mocno udokumentowane. ## Initial HTML vs Rendered HTML Dla ważnych treści i linków. ## Ustalenia dotyczące renderowania / JavaScriptu Dla każdego: Priorytet · Dowód · URL/komponent · Problem · Dlaczego ma znaczenie · Minimalna poprawka · Metoda weryfikacji ## Linkowanie wewnętrzne i architektura informacji ## Ustalenia wielojęzyczne / regionalne Lub „Nie dotyczy”. ## Ustalenia Core Web Vitals / wydajności Oddziel dane zmierzone od hipotez. ## Ustalenia dostępności / mobile ## Ustalenia dotyczące treści i semantyki ## Szybkie poprawki Tylko elementy niskiego ryzyka z jasnymi dowodami. ## Roadmapa priorytetów Top 10, uporządkowane według oczekiwanego wpływu i pewności. ## Lista weryfikacyjna Uwzględnij Search Console URL Inspection, kontrole rendered HTML, logi serwera, field CWV, profilowanie HAR/przeglądarki lub crawl tests tylko wtedy, gdy są istotne. Bądź krytyczny, techniczny i precyzyjny. Nie podawaj ogólnikowych frazesów SEO ani marketingowego wypełniacza. Nie przedstawiaj starych założeń dotyczących indeksowania JavaScriptu jako uniwersalnych faktów. Wyjaśniaj konkretne przyczyny, dowody, prawdopodobne skutki, minimalne poprawki i sposób weryfikacji każdego istotnego ustalenia.

Przeprowadzasz kompletny przegląd lokalizacji, korekty w języku natywnym, języka SEO, jakości promptów i implementacji dla istniejącej strony internetowej lub aplikacji webowej, która osiągnęła już stabilną wersję w języku źródłowym. Dane wejściowe projektu: - Nazwa projektu/strony: [PROJECT_OR_SITE_NAME] - Publiczny URL lub URL podglądu: [PUBLIC_URL_OR_PREVIEW] - Język źródłowy: [SOURCE_LANGUAGE] - Język docelowy: [TARGET_LANGUAGE] - Docelowy locale/region: [TARGET_LOCALE] - Główny rynek docelowy: [PRIMARY_MARKET_OR_REGION] - Ścieżka projektu/repozytorium: [PROJECT_PATH_OR_REPOSITORY] - Ścieżka treści w języku źródłowym: [SOURCE_CONTENT_PATH_OR_UNKNOWN] - Ścieżka treści w języku docelowym: [TRANSLATED_CONTENT_PATH_OR_UNKNOWN] - Framework, CMS, kreator strony lub stack: [FRAMEWORK_OR_CMS_OR_UNKNOWN] - Grupa docelowa: [TARGET_AUDIENCE] CEL Utwórz wersję w języku docelowym, która sprawia wrażenie, jakby od początku została zbadana, napisana, zredagowana i opublikowana dla tego locale — przy jednoczesnym zachowaniu znaczenia źródła, funkcjonalności, architektury technicznej, dostępności, intencji SEO i zachowania produktu. To nie jest zadanie polegające na tłumaczeniu słowo w słowo ani wyłącznie na sprawdzaniu pisowni. Celem jest odpowiedzialne rozszerzenie strony na użytkowników, którzy wyszukują, czytają i podejmują decyzje w języku lub regionie docelowym. Nie obiecuj, że samo tłumaczenie zwiększy pozycje lub ruch. Traktuj zlokalizowane SEO jako połączenie użytecznych lokalnych treści, odpowiednich adresów URL i sygnałów, intencji wyszukiwania, linkowania wewnętrznego, poprawności technicznej i stałej dbałości o jakość. ZASADY NIENEGOCJOWALNE - Traktuj aktualną wersję w języku źródłowym jako semantyczne źródło prawdy, chyba że projekt wyraźnie wskazuje inne źródło. - Najpierw sprawdź rzeczywistą architekturę projektu. Nie zakładaj istnienia systemu build, statycznego HTML, frameworka JavaScript, CMS-a, bazy danych, renderowania po stronie serwera, renderowania po stronie klienta ani konkretnego frameworka lokalizacyjnego. - Zachowaj istniejącą architekturę i model źródła prawdy. - Nie twórz równoległego systemu tłumaczeń, jeśli projekt już taki posiada. - Nie wprowadzaj systemu build tylko po to, aby obsłużyć lokalizację, jeśli projekt działa bez niego. - Nie tłumacz identyfikatorów kodu, nazw zmiennych, kluczy tłumaczeń, parametrów API, ścieżek plików, klas CSS, kluczy JSON/YAML, składni szablonów, adresów URL, adresów e-mail, znaków towarowych, nazw firm/produktów ani tekstu źródłowego dostarczonego przez użytkownika, chyba że projekt wyraźnie tego wymaga. - Zachowaj placeholdery, interpolację, pluralizację, markup i dynamiczne zachowanie promptów. - Nie zmieniaj po cichu faktów, gwarancji, znaczenia prawnego, cen, możliwości produktu, dat ani twierdzeń specyficznych dla dostawcy. - Nie twierdź, że treść została zrecenzowana, wyrenderowana lub przetestowana, jeśli rzeczywiście tak nie było. - Zapisuj niepewność zamiast zgadywać. - Nie proś o ujawnienie ukrytego toku rozumowania ani go nie ujawniaj. Zamiast tego proś o krótkie uzasadnienie, dowody, założenia i kroki weryfikacyjne. FAZA 0 — INWENTARYZACJA PROJEKTU I LOKALIZACJI Przed tłumaczeniem pojedynczych zdań sprawdź projekt i zidentyfikuj: - wszystkie publiczne i podglądowe trasy - trasy w języku źródłowym - trasy w języku docelowym lub dla danego locale, jeśli już istnieją - pliki treści/źródłowe - szablony/komponenty/partiale - pola CMS-a lub treści z bazy danych, jeśli dotyczy - pliki tłumaczeń i słowniki locale - nawigację, stopkę, breadcrumbs, menu, formularze, dialogi, powiadomienia, komunikaty o błędach i stany puste - metadane SEO - implementację canonical i hreflang - dane strukturalne - teksty alternatywne obrazów i etykiety dostępności - komunikaty walidacji po stronie klienta i serwera - wiadomości e-mail lub powiadomienia przechowywane w projekcie - generowane szablony promptów lub procesy AI, jeśli produkt je posiada - testy, polecenia build, linting, type checks, CI, podgląd i proces wdrożenia - przełączanie języka i zachowanie wykrywania locale - analitykę/consent/reklamy tylko w takim zakresie, w jakim zmiana locale wpływa na ich widoczny tekst lub zachowanie Podziel treści widoczne dla użytkownika na użyteczne grupy, na przykład: 1. wspólny interfejs 2. nawigacja i struktura 3. treści landing/marketingowe 4. UI produktu lub aplikacji 5. pomoc/tutoriale/treści edukacyjne 6. formularze i walidacja 7. generowane prompty/szablony, jeśli dotyczy 8. praktyczne procesy/use cases 9. FAQ 10. treści prawne/disclaimer/privacy 11. metadane SEO 12. teksty dostępności 13. dane strukturalne 14. komunikaty transakcyjne/systemowe 15. inne treści widoczne dla użytkownika Zapisz wszystko, do czego nie można uzyskać dostępu lub czego nie można sprawdzić. FAZA 1 — TŁUMACZENIE I LOKALIZACJA Tłumacz bezpośrednio z aktualnej wersji w języku źródłowym na język docelowy. Dla każdego elementu sprawdź: - znaczenie i intencję - gramatykę, pisownię, składnię, interpunkcję i kapitalizację - naturalny szyk zdań i rytm - rejestr i poziom formalności - terminologię odpowiednią dla odbiorców - słownictwo i konwencje charakterystyczne dla locale - daty, godziny, liczby, walutę, jednostki, adresy i cudzysłowy, gdy ma to znaczenie - jasność CTA i typowe konwencje interfejsu - długość tekstu i dopasowanie do UI - założenia kulturowe wymagające adaptacji - czy dosłowne tłumaczenie osłabiłoby przykład lub zadanie Preferuj naturalne pisanie w języku docelowym zamiast kopiowania struktury zdań z języka źródłowego. Nie poprawiaj stylu kosztem zmiany znaczenia. Nie upraszczaj treści eksperckich do poziomu, na którym stają się technicznie nieprecyzyjne. Nie komplikuj niepotrzebnie treści dla początkujących. FAZA 2 — DECYZJE TERMINOLOGICZNE Utwórz lub stosuj słownik terminologii specyficzny dla locale. Dla ważnych, powtarzających się terminów zdecyduj, czy należy: 1. przetłumaczyć 2. pozostawić w języku źródłowym, ponieważ termin jest utrwalony 3. pozostawić, ale wyjaśnić przy pierwszym użyciu 4. zastosować utrwaloną formę hybrydową 5. dostosować gramatycznie 6. używać skrótu po podaniu pełnego terminu 7. unikać terminu, ponieważ jest mylący, przestarzały lub zbędny Opieraj decyzje na: - rzeczywistym użyciu przez native speakerów w docelowym locale - użyciu branżowym - znajomości terminów przez odbiorców - precyzji technicznej - intencji wyszukiwania - spójności w całym produkcie - istnieniu naturalnego i utrwalonego odpowiednika Nie zakładaj, że wszystkie terminy techniczne muszą pozostać po angielsku. Nie zakładaj, że każdy angielski termin wymaga tłumaczenia. Nazwy produktów i znaki towarowe pozostają bez zmian. FAZA 3 — DYNAMICZNY UI, FORMULARZE I INTEGRALNOŚĆ SZABLONÓW Dla każdego dynamicznego tekstu lub szablonu: - sprawdź, czy wstawiane wartości pasują gramatycznie - sprawdź liczbę pojedynczą/mnogą, rodzaj, przypadek, rodzajniki i zgodność, jeśli ma to znaczenie - zachowaj zmienne i placeholdery dokładnie - sprawdź, czy opcjonalne wartości nie tworzą zepsutych zdań - sprawdź interpunkcję i cudzysłowy wokół wstawianych wartości - sprawdź stany puste, błędy, potwierdzenia, tooltipy i teksty pomocnicze - sprawdź, czy przyciski i dostępne nazwy pozostają zrozumiałe - sprawdź dopasowanie krótkich etykiet i kontrolek na szerokości mobilnej Nie testuj dynamicznych treści wyłącznie przez czytanie fragmentów źródłowych. Gdy to możliwe, wyrenderuj reprezentatywne stany. FAZA 4 — GENEROWANE PROMPTY LUB FUNKCJE AI, TYLKO JEŚLI PROJEKT JE POSIADA Jeśli produkt generuje prompty lub instrukcje AI, traktuj je jako treść funkcjonalną, a nie zwykły tekst marketingowy. Dla każdego generowanego promptu/szablonu sprawdź: - naturalną gramatykę języka docelowego - jasną instrukcję dotyczącą języka odpowiedzi, gdy jest potrzebna - czy placeholdery pozostają we właściwej kolejności - czy tekst wpisany przez użytkownika nie jest przypadkowo tłumaczony - czy nazwy produktów, adresy URL, kod i chroniona terminologia pozostają bez zmian - czy wartości opcjonalne nie psują zdania - czy formatowanie, listy, nagłówki i łamania linii pozostają czytelne - czy instrukcje nie są ze sobą sprzeczne - czy wymagany format odpowiedzi, ton, odbiorcy i ograniczenia pozostają zachowane - czy instrukcje specyficzne dla modelu/dostawcy są używane tylko wtedy, gdy są potrzebne - czy nie wprowadzono gwarantowanej dokładności lub niemożliwej pewności - czy nie jest wymagane ujawnienie ukrytego toku rozumowania W funkcji AI związanej z tłumaczeniem wyraźnie rozróżnij język źródłowy, język docelowy, korektę, rewriting, lokalizację i transkreację. Jeśli projekt nie ma promptów generowanych przez AI, oznacz tę fazę jako Nie dotyczy. FAZA 5 — LOKALIZACJA SEO I REGIONALNA INTENCJA WYSZUKIWANIA Sprawdź w języku docelowym: - tytuły stron - meta descriptions - nagłówki - widoczne treści stron - tekst linków wewnętrznych - breadcrumbs - teksty alternatywne obrazów - treści Open Graph/social, jeśli są używane - tekst danych strukturalnych, jeśli jest używany - slugi/adresy URL, jeśli lokalizacja jest częścią strategii routingu projektu Nie tłumacz słów kluczowych mechanicznie. Zbadaj, jak grupa docelowa rzeczywiście wyszukuje dany temat, gdy decyzje dotyczące słów kluczowych/intencji wyszukiwania mają znaczenie. Zachowaj naturalność tekstu; nie wstawiaj słów kluczowych w nienaturalny sposób. Dla implementacji wielojęzycznych lub wieloregionalnych: - preferuj osobne, crawlable adresy URL dla wersji językowych, jeśli pasuje to do architektury strony - używaj wzajemnego hreflang z prawidłowymi kodami języka/regionu, gdy istnieje wiele wariantów i projekt wykorzystuje hreflang - utrzymuj sygnały canonical zgodne z architekturą językową/regionalną - upewnij się, że każda zlokalizowana strona zawiera rzeczywiście zlokalizowaną główną treść i nawigację - zapewnij crawlable linki, aby użytkownicy i wyszukiwarki mogli przełączać języki - nie polegaj wyłącznie na cookies, wykrywaniu języka przeglądarki ani automatycznych przekierowaniach do udostępniania wariantów locale - utrzymuj każdą stronę głównie w jednym języku, z wyjątkiem sytuacji, gdy przykłady, nazwy, kod lub tekst źródłowy celowo pozostają inne - nie zakładaj, że dwa locale używające tego samego języka powinny mieć identyczne brzmienie Jeśli strona ma tylko jeden język docelowy i nie ma wersji alternatywnych, nie dodawaj hreflang tylko dlatego, że ten prompt o nim wspomina. FAZA 6 — TREŚCI FAKTYCZNE, PRAWNE I WYSOKIEGO RYZYKA Zidentyfikuj zmiany językowe, które mogłyby zmienić istotne twierdzenie. Zwróć szczególną uwagę na: - ceny - możliwości produktu - aktualne funkcje modeli/dostawców - twierdzenia dotyczące wydajności lub SEO - stwierdzenia prawne/regulacyjne - wyjaśnienia dotyczące prywatności/cookies/consentu - treści medyczne, finansowe, dotyczące zatrudnienia, bezpieczeństwa lub inne treści wysokiego ryzyka - gwarancje, wartości procentowe, rankingi, benchmarki, daty i limity Klasyfikuj istotne stwierdzenia odpowiednio jako: - ustalony fakt - fakt zależny od implementacji - fakt wrażliwy na czas - praktyczna heurystyka - rekomendacja redakcyjna - opinia - przykład - niepoparte twierdzenie Nie „poprawiaj” po cichu wątpliwego twierdzenia faktycznego tak, jakby był to zwykły problem tłumaczeniowy. Zapisz je osobno i weryfikuj istotne korekty w autorytatywnych źródłach, gdy to możliwe. W przypadku tekstów prawnych zachowaj znaczenie i zakres. Nie twierdź, że przeprowadzono przegląd prawny, jeśli faktycznie nie zrobiła tego wykwalifikowana osoba. FAZA 7 — DOSTĘPNOŚĆ I JĘZYK UX Sprawdź: - cel linków - etykiety przycisków - etykiety formularzy i powiązania błędów - aria-label i dostępne nazwy - teksty widoczne tylko dla czytników ekranu - instrukcje rozwijania/zwijania - etykiety dialogów i menu - nazwy w selektorze języka - powtarzające się linki i kontrolki wyłącznie z ikoną Teksty dostępności powinny opisywać cel/funkcję, a nie tylko wygląd wizualny. Dosłowne tłumaczenie może być poprawne gramatycznie, ale nadal stanowić słabą etykietę UI; wybieraj naturalną konwencję języka docelowego, gdy znaczenie zostaje zachowane. FAZA 8 — PIERWSZA KOREKTA Po zakończeniu początkowego tłumaczenia przeprowadź pełną korektę redakcyjną wszystkich plików w języku docelowym. Systematycznie sprawdź: - struktury zdań z języka źródłowego - dosłowne tłumaczenia - rytm charakterystyczny dla tłumaczenia maszynowego - niespójną terminologię - niespójny formalny/nieformalny sposób zwracania się do użytkownika - powtarzające się frazy przetłumaczone różnie bez powodu - nieprzetłumaczone fragmenty - przypadkowo mieszane językowo instrukcje - błędy interpunkcyjne i typograficzne - niespójną kapitalizację - nienaturalne CTA - niezręczne nagłówki - zepsute formatowanie linii/list w długich promptach - przypadkowo zmienione placeholdery lub zmienne - rozbieżność znaczenia między źródłem a tłumaczeniem Nie wdrażaj szerokich globalnych zamian bez sprawdzenia każdego wystąpienia w kontekście. FAZA 9 — IMPLEMENTACJA Wdrażaj wyłącznie zaakceptowane/poprawne zmiany. Podczas implementacji: - zachowuj kodowanie i formatowanie, gdy jest to praktyczne - zachowuj pliki będące źródłem prawdy i workflow generowanego outputu - zachowuj klucze tłumaczeń i placeholdery - zachowuj strukturę HTML/Markdown/JSX/szablonów - zachowuj kod i chronione terminy - unikaj niezwiązanych refactoringów - unikaj zmian formatowania całych plików - aktualizuj źródło, metadane, schema, routing/config i generowany output razem tylko wtedy, gdy wymaga tego architektura - przestrzegaj istniejących zasad build/deployment projektu Nie edytuj generowanego outputu zamiast jego źródła, chyba że projekt wyraźnie traktuje generowany output jako utrzymywane źródło. FAZA 10 — TECHNICZNE QA Uruchom odpowiednie istniejące kontrole projektu, na przykład: - build - lint - type checking - testy unit/integration/E2E - walidację kluczy lokalizacyjnych - kontrole brakujących/zduplikowanych tłumaczeń - spójność placeholderów - kontrole linków wewnętrznych - walidację HTML/JSON/YAML/schema - kontrole dostępności - kontrole metadanych SEO - kontrole canonical/hreflang - kontrole responsive/overflow - testy przeglądarkowe - kontrole parytetu generowanego outputu Nie osłabiaj testu tylko po to, aby przeszedł. Aktualizuj testy exact-text, gdy zaakceptowana zmiana językowa zgodnie z planem zmienia tekst widoczny dla użytkownika. FAZA 11 — DRUGA, NIEZALEŻNA KOREKTA Po implementacji i po ponownym zbudowaniu/wyrenderowaniu projektu przeprowadź drugą pełną korektę językową z perspektywy doświadczonego redaktora języka docelowego. Ta druga korekta jest obowiązkowa i nie może być jedynie mechanicznym powtórzeniem pierwszej checklisty. Sprawdź finalne brzmienie w kontekście i ponownie porównaj je ze znaczeniem wersji w języku źródłowym. W szczególności sprawdź: - każdą zmienioną stronę/trasę - tytuł strony i meta description - nagłówki H1/H2/H3 - nawigację i breadcrumbs, które się zmieniły - przyciski i CTA - formularze i stany walidacji - długie bloki promptów i zamierzone łamania linii - przykłady i dynamiczne kombinacje placeholderów - etykiety i zawijanie na szerokości mobilnej - etykiety dostępności - treści widoczne i ukryte/progresywne - zlokalizowane linki wewnętrzne - słownictwo i rejestr docelowego locale - brak nieprzetłumaczonych fragmentów języka źródłowego poza zamierzonymi nazwami/terminami technicznymi/przykładami - brak dryfu regionalnego, szczególnie gdy kilka locale używa tego samego języka Gdy to możliwe, sprawdź wyrenderowaną stronę, a nie tylko pliki źródłowe. Jeśli renderowanie w przeglądarce jest niedostępne, zaznacz to ograniczenie i przeprowadź drugą korektę na poziomie źródła bez twierdzenia, że wykonano przegląd wyrenderowanej strony. FAZA 12 — WERYFIKACJA KOŃCOWA Zanim uznasz locale za kompletne: 1. Ponownie przeskanuj zmienione pliki pod kątem nieprzetłumaczonego tekstu źródłowego. 2. Ponownie przeskanuj je pod kątem odrzuconych lub zastąpionych sformułowań. 3. Sprawdź placeholdery, zmienne, interpolację i zachowanie szablonów promptów. 4. Sprawdź zlokalizowane trasy i linki wewnętrzne. 5. Sprawdź relacje canonical/hreflang, jeśli dotyczy. 6. Sprawdź metadane, teksty alt i etykiety dostępności. 7. Sprawdź dane strukturalne, jeśli występują. 8. Uruchom build i odpowiednie testy automatyczne. 9. Gdy to możliwe, sprawdź reprezentatywne strony na szerokościach telefonu, tabletu i desktopu. 10. Jeśli projekt obsługuje motywy, sprawdź light/dark mode. 11. Przeczytaj finalną zmienioną treść jeszcze raz jako ciągły tekst w języku natywnym, a nie jako pojedyncze fragmenty zdań. OUTPUT / RAPORT Przekaż: ## Podsumowanie lokalizacji - język i locale docelowe - zmienione pliki/trasy - wykrytą architekturę/system lokalizacji - co zostało przetłumaczone/zlokalizowane - co celowo pozostawiono bez zmian ## Decyzje terminologiczne Ważne terminy przetłumaczone, zachowane, wyjaśnione lub specyficzne dla locale. ## Ustalenia i decyzje Dla każdego istotnego problemu: ID · Ważność · Typ · Tekst źródłowy · Aktualny tekst docelowy · Proponowany tekst · Uzasadnienie · Status (Zaakceptowano/Zmodyfikowano/Odrzucono/Wymaga decyzji człowieka) · Odniesienie do implementacji ## Decyzje SEO / regionalne Uwzględnij adresy URL, strategię hreflang/canonical, decyzje dotyczące slugów i adaptacje intencji wyszukiwania tylko wtedy, gdy mają zastosowanie. ## Pierwsza korekta Co zostało sprawdzone i poprawione. ## Druga korekta Potwierdź, że odbyła się oddzielna druga korekta, jakie problemy końcowe wykryła i czy sprawdzano wyrenderowane strony, czy wyłącznie źródło. ## Walidacja techniczna Wymień tylko testy/kontrole, które rzeczywiście uruchomiono, wraz z ich wynikami. ## Pozostałe ryzyka lub decyzje człowieka Uwzględnij kwestie prawne, faktyczne, terminologiczne, rynkowe, layoutowe lub przeglądarkowe, które nadal wymagają osoby. ## Zmienione pliki Dokładna lista. STANDARD KOŃCOWY Zlokalizowana wersja powinna brzmieć naturalnie dla grupy docelowej, zachowywać znaczenie źródła i zachowanie produktu, respektować rzeczywistą architekturę projektu, używać terminologii odpowiedniej dla locale, pozostawać spójna technicznie i pod kątem SEO oraz przejść niezależną drugą korektę po implementacji. Nie opisuj lokalizacji jako „sprawdzonej przez native speakera”, „sprawdzonej przez człowieka”, „sprawdzonej prawnie” ani „przetestowanej w przeglądarce”, jeśli taki przegląd rzeczywiście się nie odbył.