Ukośnik na końcu adresu URL: jak naprawić duplikaty stron na NGINX

Adresy URL z ukośnikiem na końcu tworzą duplikaty stron, gdy /page i /page/ zwracają kod 200 z tą samą treścią. Rozwiązanie jest proste. Wybierz jedną formę, a drugą przekieruj na nią przez 301, na własnym serwerze NGINX (origin) albo w CMS-ie. Widzisz w logach dostępu lub w Search Console tę samą stronę dwa razy, raz z ukośnikiem, a raz bez? To prawie zawsze właśnie z tego powodu. Poniżej: wybór formy, sprawdzenie, co serwer zwraca w tej chwili, reguły NGINX i miejsce tagów canonical (uprzedzam: to zabezpieczenie, a nie rozwiązanie).

Dlaczego /page i /page/ to dwa różne adresy URL?

Dla robota adres z ukośnikiem na końcu i adres bez niego to dwa osobne adresy. Nawet jeśli treść jest identyczna co do bajtu. Takie rozdwojenie ma zwykle kilka przyczyn. Serwery WWW od dawna traktują ścieżki zakończone ukośnikiem jak katalogi, a ścieżki bez niego jak pliki. Do tego dochodzi CMS, który generuje jedną formę, ale bez problemu przyjmuje obie. A linki wewnętrzne i mapy witryny z czasem się rozjeżdżają, aż zaczynają mieszać obie wersje. Poradnik Google o łączeniu zduplikowanych adresów wyjaśnia, ile to kosztuje: sygnały takie jak linki rozkładają się na kopie, zamiast skupiać się na jednym preferowanym adresie, a Googlebot traci czas na duplikaty zamiast na nowe lub zaktualizowane strony. Jedna rzecz, w której ludzie często się mylą. Żadna z form nie pozycjonuje się lepiej. Problemem jest wyłącznie posiadanie obu.

Wybierz jedną formę adresów z ukośnikiem lub bez i trzymaj się jej

Obie formy są w porządku. Naprawdę. Liczy się spójność adresów URL w całym serwisie. Zacząłbym od tego, co już generuje Twój CMS, bo walka z jego strukturą bezpośrednich odnośników oznacza tylko więcej reguł do pilnowania później. Następnie sprawdź, której formy używa większość linków wewnętrznych i zewnętrznych. Przekierowanie mniejszej grupy oznacza mniej adresów do ruszenia. Pliki to osobny przypadek: adresy kończące się na .pdf, .xml czy .jpg nigdy nie dostają ukośnika.

Gdy już zdecydujesz, wszystko musi wskazywać tę samą formę:

• ustawienia bezpośrednich odnośników w CMS-ie
• linki wewnętrzne w treści i szablonach
• mapa witryny XML
• menu nawigacyjne, okruszki i linki w stopce
• adnotacje hreflang, jeśli serwis ma wersje językowe

Jak sprawdzić, co serwer zwraca dzisiaj

Odpytaj obie wersje przez curl -I i porównaj kody odpowiedzi oraz nagłówki Location. Na przykład curl -I https://example.com/page, a potem to samo z /page/. Dwa razy 200? Masz duplikaty. Chodzi Ci o 301 wskazujące wybraną formę. A 302 to przekierowanie tymczasowe, więc zamień je na stałe.

Przy okazji sprawdź, czy „zła” wersja nie serwuje ubogiej lub pustej strony z kodem 200. Niektóre reguły awaryjne robią dokładnie to (po cichu, oczywiście), a Google może takie strony zaliczyć do stron uznanych przez Google za nieistniejące. I ostatnia rzecz: upewnij się, że przekierowanie trafia od razu na docelowy adres. Jeśli tworzy łańcuch z osobnym przeskokiem z http na https albo na www, dokładasz kroki, które mogła załatwić jedna reguła.

Reguły rewrite w NGINX: dodawanie lub usuwanie ukośnika przez 301

W NGINX jedna reguła rewrite w bloku server kieruje każdą niepreferowaną wersję na wybraną formę przez 301. Kolejność działań:

1. Zrób kopię zapasową konfiguracji serwisu, na przykład kopiując plik z /etc/nginx/sites-available/.
2. Dodaj jedną z poniższych reguł wewnątrz bloku server.
3. Uruchom nginx -t, żeby sprawdzić składnię.
4. Przeładuj konfigurację poleceniem systemctl reload nginx.
5. Powtórz sprawdzenie przez curl dla obu wersji kilku stron.

Aby usunąć ukośnik, bez ruszania prawdziwych katalogów i katalogu głównego /:

if (!-d $request_filename) {
    rewrite ^/(.+)/$ /$1 permanent;
}

Aby dodać ukośnik, bez ruszania prawdziwych plików i ścieżek z rozszerzeniem pliku:

if (!-f $request_filename) {
    rewrite ^([^.]*[^/])$ $1/ permanent;
}

Flaga permanent zwraca 301, co mówi wyszukiwarkom, że przeniesienie jest ostateczne. Z kolei 302 oznacza, że pierwotny adres nadal obowiązuje. Nie rozstrzyga więc, którą wersję zostawić. Więcej o tym rozumowaniu znajdziesz w tekście o regułach 301 dla wariantów adresów. A według podlinkowanej wyżej strony Google wszystkie metody stałego przekierowania działają w wyszukiwarce tak samo. Różnić się może jedynie czas, po jakim wyszukiwarki je zauważą.

Działasz za reverse proxy, takim jak Jalvo? Wtedy reguła trafia na Twój serwer NGINX (origin) albo do CMS-a. Upewnij się też, że origin nie jest dostępny pod drugą nazwą hosta. To cały dodatkowy zestaw kopii, opisany w tekście o zduplikowanych hostach za proxy.

Gdzie pasuje kanoniczny adres URL

Tag rel=canonical to wskazówka, która wspiera przekierowanie. Nie zastępuje go. Strona Google wymienia trzy sposoby wskazania kanonicznego adresu URL. Po pierwsze, element link w sekcji head strony. Po drugie, nagłówek HTTP rel=canonical, przydatny przy plikach innych niż HTML, na przykład PDF. Po trzecie, podanie kanonicznych adresów w mapie witryny, co Google określa jako słabszy sygnał niż dwa pozostałe.

Moja rada: ustaw na każdej stronie canonical wskazujący na nią samą, zapisany w wybranej formie z ukośnikiem lub bez, żeby nigdy nie przeczył przekierowaniu. Ustaw go w CMS-ie albo w szablonach stron na originie. Dzięki temu nowe strony dostaną go automatycznie i nikt nie musi o tym pamiętać.

Spójność adresów z ukośnikiem na końcu sprowadza się więc do kilku nawyków. Jedna forma. Jedna reguła 301 w NGINX albo w CMS-ie, która jej pilnuje. Canonicale i mapa witryny w tej samej formie. Po zmianie przejrzyj logi dostępu i Search Console i potwierdź, że każda strona jest pobierana i indeksowana tylko w jednej wersji. Potem zrób to ponownie po aktualizacjach CMS-a lub zmianach w konfiguracji serwera, bo one potrafią po cichu przywrócić drugą formę.

FAQ