SEO stron statycznych: 8 pułapek, które mogą ograniczyć widoczność

Ten sam adres może działać w dwóch wersjach: /kontakt/ lub /kontakt. Problem pojawia się wtedy, gdy framework (np. Astro) stosuje inne zasady niż hosting (np. Netlify). Wtedy sitemap może wskazywać jeden adres, canonical drugi, a linki wewnętrzne trzeci.

To prosta droga do duplikacji treści i rozproszenia sygnałów rankingowych. Google zaleca, aby sitemap zawierała preferowane, kanoniczne adresy URL, a nie wszystkie warianty prowadzące do tej samej treści.

Co zrobić?

Wybierz jeden format adresów — z ukośnikiem albo bez niego. Następnie ustaw tę samą regułę w frameworku, hostingu, CDN, sitemapie, tagach canonical i linkowaniu wewnętrznym. Na końcu sprawdź, czy alternatywna wersja adresu przekierowuje na właściwy URL.

W CMS-ie zaznaczasz opcję „nie indeksuj" i często na tym kończy się problem. Wtyczka usuwa stronę z sitemap. Na stronie statycznej sitemap zwykle powstaje podczas buildu. Jeśli nie dodasz odpowiedniej reguły, trafią do niej wersje robocze, strony podziękowania, panele administracyjne albo adresy oznaczone jako noindex.

Co zrobić?

• Dodaj w danych strony oznaczenie noindex: true
• Wykluczaj takie adresy z sitemap i RSS feedu
• Nie dodawaj do sitemap stron przekierowujących i błędnych
• Generuj robots.txt automatycznie
• Wskaż w nim właściwą sitemapę: Sitemap: https://twojadomena.pl/sitemap.xml

W sitemapie umieszczaj tylko adresy, które chcesz pokazywać w wynikach wyszukiwania.

Niektóre frameworki mają własne narzędzia do optymalizacji grafik. Next.js korzysta z komponentu <Image>, który może automatycznie zmieniać rozmiar, dobierać format i obsługiwać lazy loading. Problem zaczyna się, gdy omijasz ten mechanizm — wrzucasz duży plik przez zwykły tag <img> bez kompresji.

Efekt? Strona waży więcej, wolniej ładuje się na smartfonach i osiąga słabsze wyniki Core Web Vitals. Często brakuje też atrybutu alt.

Co zrobić?

• Korzystaj z image pipeline dostępnego w frameworku
• Zapisuj grafiki w formacie WebP lub AVIF
• Podawaj szerokość i wysokość obrazów
• Stosuj lazy loading dla grafik poza pierwszym ekranem
• Dodawaj opisowe atrybuty alt
• Kompresuj pliki przed publikacją

Na stronie statycznej tytuły, opisy, canonicale i dane strukturalne często powstają na podstawie wspólnego szablonu. Jeden błąd może pojawić się na dziesiątkach albo setkach podstron jednocześnie. Przykład: dodajesz nazwę firmy do każdego tytułu w złym miejscu — nagle wszystkie <title> stają się zbyt długie.

Co zrobić?

• Sprawdzaj szablony na różnych typach podstron
• Kontroluj długość i unikalność tytułów
• Twórz indywidualne opisy dla ważnych landing pages
• Upewnij się, że każda strona ma właściwy canonical
• Testuj JSON-LD w Google Rich Results Test
• Po wdrożeniu monitoruj błędy danych strukturalnych

Schema.org musi opisywać to, co rzeczywiście znajduje się na stronie. Nie dodawaj znaczników tylko dlatego, że mogą wygenerować wynik rozszerzony.

Wyobraź sobie: użytkownik wpisuje nieistniejący adres, widzi estetyczną stronę „Nie znaleziono" — ale serwer zwraca kod 200 OK. Dla robota to działająca strona. Wyszukiwarka zaczyna indeksować nieistniejące adresy, a crawl budget ucieka na strony, których nie ma.

Co zrobić?

• Przygotuj własny szablon 404
• Upewnij się, że nieistniejące adresy zwracają HTTP 404
• Testuj faktyczny kod odpowiedzi, nie tylko wygląd strony
• Nie przekierowuj wszystkich błędnych adresów na stronę główną
• Dla trwale usuniętych zasobów rozważ kod 410

Google wyraźnie rozróżnia stronę, która tylko wygląda jak 404, od odpowiedzi zawierającej prawdziwy status 404.

Kod generowany przez AI potrafi przyspieszyć pracę. Potrafi też wprowadzić bałagan. Menu może prowadzić do /oferta/, stopka do /oferta, a kafelek na stronie głównej do ../oferta. Dla człowieka różnica jest niewielka. Dla crawlera to trzy warianty tej samej ścieżki.

Co zrobić?

• Ustal jeden standard adresowania
• Generuj linki z centralnego systemu routingu
• Nie kopiuj ręcznie ścieżek w wielu komponentach
• Sprawdzaj różnice między linkami względnymi i absolutnymi
• Skanuj stronę crawlerem (np. Screaming Frog lub Sitebulb)
• Usuń linki prowadzące do przekierowań i błędów 404

Strona statyczna nie wykonuje zapytań do bazy danych przy każdym wejściu — to pomaga. Nie rozwiązuje jednak wszystkich problemów z wydajnością. Możesz wygenerować szybki HTML, a jednocześnie wysłać kilka megabajtów JavaScriptu i CSS-u, z których użytkownik potrzebuje tylko niewielkiej części.

Wynik? Gorsza interaktywność, dłuższe ładowanie i słabsze Core Web Vitals.

Co zrobić?

• Sprawdź stronę w Lighthouse i PageSpeed Insights
• Ograniczaj JavaScript wysyłany do przeglądarki
• Stosuj code splitting i tree shaking
• Usuń nieużywane biblioteki oraz style
• Ładuj elementy spoza pierwszego ekranu z opóźnieniem
• Testuj serwis na telefonie, nie tylko na szybkim komputerze

Statyczny HTML to dopiero początek. Liczy się cały front-end.

Migracja z WordPressa do Astro, Gatsby czy Next.js zmienia znacznie więcej niż wygląd strony. Zmieniasz routing, sposób generowania metadanych, sitemapę, dane strukturalne i obsługę przekierowań. Nowa witryna może wyglądać identycznie, ale w Google stracić ruch — wystarczy kilka zapomnianych przekierowań 301.

Co zrobić przed migracją?

• Zbierz listę wszystkich starych adresów
• Sprawdź dane z Google Search Console, Analytics i crawlera
• Przygotuj mapę starych i nowych URL-i
• Dodaj przekierowania 301 tam, gdzie adres się zmienia
• Porównaj stare i nowe canonicale
• Sprawdź metadane, Schema.org, sitemapę i linkowanie wewnętrzne
• Nie kieruj wszystkich starych adresów na stronę główną
• Po publikacji przeskanuj wersję produkcyjną

Migrację potraktuj jak projekt SEO, a nie zwykłą zmianę technologii. To robi różnicę.

Szybka lista kontrolna — przed publikacją strony statycznej sprawdź:

• Czy wszystkie ważne podstrony zwracają poprawny kod HTTP?
• Czy sitemap zawiera wyłącznie kanoniczne adresy?
• Czy strony noindex są wykluczone z sitemap?
• Czy robots.txt istnieje i wskazuje właściwą sitemapę?
• Czy linki wewnętrzne korzystają z jednego formatu URL?
• Czy obrazy mają właściwe rozmiary i atrybuty alt?
• Czy dane Schema.org przechodzą walidację?
• Czy strona 404 zwraca faktyczny kod 404?
• Czy stara struktura adresów została porównana z nową?
• Czy przekierowania działają na wersji produkcyjnej?
• Czy JavaScript i CSS nie obciążają strony bardziej, niż to konieczne?

Strona statyczna może być szybka, skalowalna i wygodna w utrzymaniu. Nie zadba jednak sama o swoje SEO. Jeśli pominiesz konfigurację adresów, sitemap, metadanych, statusów HTTP i przekierowań, nowoczesny stack technologiczny nie uchroni Cię przed utratą widoczności.