Wdrożyłem aktualizację sitemapy z około 3 000 nowych stron pod /en/blog/.... Niedługo później w Yandex Webmaster zauważyłem nieoczekiwany wzorzec: Yandex próbował crawlować odpowiadające im ścieżki /blog/..., bez prefiksu /en.
Gdyby te URL-e po prostu zwracały 404, mogłem dostać tysiące niepotrzebnych prób crawlowania nieistniejących ścieżek. Na szczęście wcześniej skonfigurowałem stałe przekierowania 308 z tras bez prefiksu językowego na właściwe angielskie URL-e.
Ta niewielka warstwa defensywnego routingu okazała się znacznie bardziej wartościowa, niż zakładałem.
Co naprawdę zaobserwowałem
- Opublikowałem sitemapę z około 3 000 nowymi stronami w strukturze
/en/blog/.... - Yandex Webmaster pokazał później próby crawlowania odpowiadających adresów
/blog/.... - Te alternatywne ścieżki były już objęte 308.
- Zamiast kończyć na 404, żądania trafiały na docelowe
/en/blog/....
Muszę jednak poprawić jedno stwierdzenie z pierwotnej wersji: nie potrafię udowodnić, że Yandex „źle sparsował sitemapę”. Zobaczyłem nietypowe ścieżki po aktualizacji, ale sama kolejność zdarzeń nie dowodzi wewnętrznej przyczyny. Wyszukiwarki mogą odkrywać URL-e z różnych sygnałów i źródeł historycznych. Bez mocniejszych dowodów poprawne stwierdzenie brzmi po prostu: Yandex crawlował ścieżki, których się nie spodziewałem.
To ważne rozróżnienie. Dziwny URL w żądaniu crawlera jest obserwacją. Wyjaśnienie, dlaczego crawler wybrał właśnie ten URL, jest osobną tezą.
Dlaczego 308 były przydatne
Moja logika traktowała krótszą ścieżkę jako stały alias lokalizowanego URL-a:
/blog/example-post -> 308 -> /en/blog/example-postDzięki temu crawler, nawet jeśli wchodził przez niespodziewany adres, docierał do strony, którą faktycznie chciałem serwować.
308 Permanent Redirect to stałe przekierowanie HTTP zachowujące metodę i body żądania. Przy zwykłych GET-ach crawlera zachowanie metody zwykle nie jest kluczowe; tutaj liczyło się przede wszystkim to, że przekierowanie jest jawnie permanentne. Aktualna dokumentacja Yandex Webmaster klasyfikuje zarówno 301, jak i 308 jako stałe przekierowania.
Oficjalna dokumentacja Yandex Webmaster o przekierowaniach.
Nie oznacza to, że 308 jest automatycznie lepsze od 301 dla SEO. W moim przypadku 308 już istniały i spełniły konkretną rolę: niespodziewany URL nie stawał się ślepą uliczką.
Przekierowanie to siatka bezpieczeństwa, nie naprawa sitemapy
Przekierowania ograniczyły skutki, ale nie sprawiły, że zbędny crawl był pożądany. Każde niepotrzebne przekierowanie to dodatkowe żądanie i dodatkowy hop. Zbyt szeroka reguła może też ukrywać błędy generowania URL-i, jeśli przestaniemy szukać ich źródła.
Jeśli sama sitemap zawiera stare albo redirectujące URL-e, należy poprawić sitemapę i wskazać adresy końcowe. Redirecty powinny obsługiwać stare, alternatywne lub przypadkowo odkryte ścieżki, a nie usprawiedliwiać niedokładne dane.
U mnie sitemap zawierała już /en/blog/.... Przekierowania po prostu zwiększały odporność strony, gdy crawler trafiał przez /blog/....
Co dziś bym sprawdził
- Otworzyć rzeczywiście wdrożoną sitemapę. Nie ufać wyłącznie generatorowi; sprawdzić plik i próbkę URL-i.
- Sprawdzić odpowiedzi końcowe. URL-e przeznaczone do indeksowania powinny najlepiej trafiać od razu na właściwą stronę.
- Przetestować przewidywalne alternatywne ścieżki. Jeśli stary URL ma stały odpowiednik, mapowanie powinno być jednoznaczne i 1:1.
- Unikać łańcuchów.
A -> B -> Cjest trudniejsze do kontrolowania niżA -> C. - Jeśli to możliwe, porównywać raporty crawlera z danymi serwerowymi. Webmaster tools nie zawsze pokazują, skąd wyszukiwarka po raz pierwszy poznała URL.
- Nie wyciągać wniosków o rankingu z samego crawlowania. Crawling, indeksowanie, ranking i ruch to różne etapy.
curl -I https://example.com/blog/example-post
HTTP/2 308
location: https://example.com/en/blog/example-postTo tylko przykład ilustracyjny. Chodzi o to, by sprawdzić dokładny status i dokładny cel zamiast zakładać, że reguła działa.
Co mogę stwierdzić, a czego nie
Mogę potwierdzić, że istniejące 308 sprawiły, iż niespodziewane żądania /blog/... nie kończyły się 404 i trafiały na docelowe URL-e.
Nie mogę potwierdzić, że przyczyną był parser sitemapy Yandex. Nie mierzyłem też wzrostu pozycji, poprawy indeksowania ani konkretnej ilości „uratowanego” ruchu. Takie stwierdzenia wykraczałyby poza moje dane.
Wniosek jest węższy i bardziej użyteczny: architektura URL powinna tolerować przewidywalne błędy na granicach systemu. Czysta sitemap to pierwsza linia obrony. Precyzyjna warstwa stałych redirectów — druga.
Gdy działają obie, niespodziewana ścieżka crawlera znacznie rzadziej zamienia się w tysiące martwych URL-i.