Indeksowanie fragmentów adresu URL

Indeksowanie fragmentów URL to w większości problem z przeszłości, ale wciąż pojawia się w audytach SPA co miesiąc. Jeśli ważna treść wyświetla się tylko pod /page#state lub /page#!/view, Google zwykle traktuje to jako ten sam URL co /page, a nie jako osobny dokument.

Wpływ biznesowy jest prosty. Ukryte URL-e nie pozycjonują się. Stany produktu, artykuły pomocy, filtrowane widoki kategorii i trasy aplikacji mogą zniknąć z wyników wyszukiwania nawet wtedy, gdy użytkownicy mają do nich dostęp w przeglądarce bez problemów.

Co Google faktycznie robi z fragmentami

Przy standardowym indeksowaniu wyszukiwarki usuwają fragment. Google wycofało starą metodę indeksowania AJAX-a lata temu, co zakończyło działanie dawnego obejścia opartego na #!. W praktyce Googlebot żąda bazowego URL, a nie każdej odmiany hasha nałożonej na niego.

To oznacza, że example.com/docs#setup nie jest drugą stroną. Zwykle jest to po prostu example.com/docs z przejściem/skokiem w obrębie tej strony. Jeśli router w React lub Vue nadal opiera się na stanach opartych na hashach, aby treści były unikalne, masz problem z indeksacją, a nie drobną techniczną osobliwość.

Uczciwe zastrzeżenie: fragmenty sprawdzają się do kotwic, zakładek i linków prowadzących do określonych miejsc na stronie, która sama w sobie jest już indeksowalna. Kłopot zaczyna się wtedy, gdy zespoły oczekują, że fragmenty utworzą samodzielne wpisy w wyszukiwarce.

Gdzie to psuje wyniki SEO

• SPA z routowaniem na hashach: trasy typu /#/pricing lub /#!/features często sprowadzają się do jednego URL, który da się zindeksować.
• Nawigacja fasetowa: filtry ładowane wyłącznie przez fragmenty nie są w stanie zdobywać pozycji dla kombinacji long-tail.
• Huby dokumentacji: stany artykułów renderowane za fragmentami często nie są indeksowane osobno.
• Niedoprecyzowanie siły linków: backlinki do wariantów z fragmentami rzadko generują osobne sygnały rankingowe dla tych stanów.

W Screaming Frog zwykle widać to jako jeden URL HTML z wieloma zmianami stanu JavaScript, ale bez wyraźnie odrębnych ścieżek możliwych do crawlowania. W Google Search Console obserwujesz wyświetlenia skoncentrowane na bazowym URL, podczas gdy rzekome widoki potomne nie dostają nic. Ahrefs i Semrush następnie raportują mniej URL-i z pozycjami, niż zakłada zespół produktowy.

Co zamiast tego

1. Przenieś istotne stany na prawdziwe URL-e, stosując routowanie oparte o ścieżki (path-based) albo parametry zapytania.
2. Renderuj treść indeksowalną po stronie serwera lub zastosuj pre-renderowanie w ramach, takich jak Next.js, Nuxt czy Astro.
3. Ustaw canonicale na nowe URL-e, a nie na wersje z fragmentami.
4. Zaktualizuj linkowanie wewnętrzne, mapy XML sitemap i nawigację, aby Google mogło odkryć nowe ścieżki.
5. Zweryfikuj to przez Inspekcję adresu URL (URL Inspection) w GSC, renderowane crawle w Screaming Frog oraz logi (jeśli je masz).

Jeśli to migracja, odwzoruj stare kierowania użytkowników opartych na fragmentach na odpowiednie URL-e możliwe do crawlowania, o ile to możliwe. W ścisłym sensie nie możesz zrobić przekierowania 301 dla fragmentu, ponieważ fragment jest obsługiwany po stronie klienta i nie jest wysyłany w żądaniu HTTP. To zastrzeżenie wiele słowników pomija. Potrzebujesz obsługi JavaScript, aktualizacji linków wewnętrznych i odzyskania linków zewnętrznych w Ahrefs lub Moz, a nie „zgrabnej” reguły przekierowania po stronie serwera.

Podsumowanie: fragmenty służą do pozycjonowania na stronie, a nie do indeksowalnych dokumentów. Jeśli dana strona ma znaczenie dla ruchu organicznego, daj jej prawdziwy URL.