Napraw kanoniczny URL wskazujący na staging

Jak wygląda ten objaw

Każda strona na żywej witrynie serwuje kanoniczny adres wskazujący inny host:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">

Search Console pokazuje to jako "Duplikat, Google wybrał inny kanoniczny adres niż użytkownik" albo jako strony wypadające z indeksu z kanonicznym adresem zadeklarowanym przez użytkownika na hoście, którego nigdy nie zweryfikowałeś. Ponieważ host staging jest zwykle nieosiągalny, chroniony hasłem albo oznaczony noindex, konsolidacja nie ma gdzie wylądować, więc żywe strony po prostu przestają się rankingować, ponowne indeksowanie po ponownym indeksowaniu. Nic nie zwraca 500, żadna kontrola uptime niczego nie zauważa, i właśnie dlatego jest to kosztowne.

Skąd bierze się zły base URL

• Baza danych przywrócona ze staging. W WordPressie wiersze opcji siteurl i home przenoszą nazwę hosta staging na produkcję, a za nimi podąża każdy generowany URL.
• Zmienna środowiskowa we wdrożonej wersji. URL strony zapieczony na etapie budowania, więc skompilowany wynik niesie wartość ze staging bez względu na to, co mówi środowisko wykonawcze.
• Domyślny host frameworka konfigurowany per środowisko, gdzie konfiguracja produkcyjna nigdy nie została zaktualizowana po tej dla staging.
• Zakodowany na sztywno bezwzględny URL we współdzielonym layoucie albo ustawieniu wtyczki SEO, zapisany podczas migracji i nigdy niesprawdzony ponownie.
• Zbuforowana strona zbudowana na złym hoście. CDN albo pełnostronicowy cache wypełniony buildem ze staging serwuje nieaktualny HTML z kanonicznym adresem staging długo po poprawieniu konfiguracji.

Napraw wartość, a potem usuń całą klasę błędu

1. Popraw zapisany base URL dla produkcji, w którymkolwiek z powyższych miejsc, które ma zastosowanie. W WordPressie to dwa wiersze opcji plus wszelkie bezwzględne URL-e zapisane w treści wpisów przez kopię ze staging.
2. Przebuduj i wdróż ponownie, jeśli wartość jest wkompilowana. Zmiana zmiennej środowiskowej bez przebudowy zostawia starą wartość w wysłanym pakiecie.
3. Wyczyść każdy cache na trasie: aplikacji, CDN i brzegu sieci jednakowo. Poprawione źródło za cache'em pełnym HTML-a ze staging wygląda na nienaprawione tak długo, jak żyje ten cache.
4. Wybieraj wyprowadzanie kanonicznego adresu z hosta żądania zamiast odczytu zapisanej stałej. Kanoniczny adres zbudowany na podstawie hosta, który obsłużył żądanie, nie może być błędny w środowisku, z którego został zserwowany, co usuwa całą klasę awarii, a nie tylko ten jeden jej przypadek.
5. Trzymaj staging poza indeksem innymi sposobami. Uwierzytelnianie HTTP albo lista dozwolonych adresów IP na hoście staging to właśnie to, co powinno go chronić, a nie kanoniczny adres, i nie noindex, który może wędrować razem z plikiem konfiguracji.

Zweryfikuj naprawę na produkcji

Czytaj odpowiedź, nie szablon, bo wtyczki, edge workery i cache'e wszystkie wstrzykują kanoniczne adresy, które nie pojawiają się w Twoim repozytorium:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'

Następnie sprawdź więcej niż jedną stronę. Kanoniczny adres jest generowany przez szablon, więc poprawność na stronie głównej niczego nie dowodzi o stronach produktowych, paginowanych listingach czy czymkolwiek renderowanym innym layoutem. W Search Console URL Inspection pokazuje kanoniczny adres zadeklarowany przez użytkownika obok tego wybranego przez Google, a zgodność obu po ponownym indeksowaniu to potwierdzenie, które się liczy. To ponowne indeksowanie trwa dni, więc poprawiony kanoniczny adres nie przywraca ruchu tego samego popołudnia.

Zapobiegnij ponownemu wysłaniu tego błędu

Dwa zabezpieczenia kosztują niemal nic. Pierwsze to asercja w momencie wdrożenia: po wydaniu pobierz garść produkcyjnych adresów URL i przerwij wdrożenie, jeśli którykolwiek kanoniczny adres nazywa host inny niż produkcyjny. Drugie to dalsze obserwowanie później, bo ta awaria z równym prawdopodobieństwem przyjdzie z przywróceniem bazy danych albo ustawieniem wtyczki, co z wdrożeniem kodu. Kontrole HTTP HostTracker mogą asertować na treści i nagłówkach odpowiedzi, więc zaplanowaną kontrolę można ustawić tak, żeby nie zaliczała się, gdy tag kanoniczny na stronie nie jest taki, jak oczekujesz, a taka awaria alertuje jak każda inna.

Sprawdź każdy szablon, nie jedną stronę

Zacznij od jednego dotkniętego URL-a w darmowym sprawdzeniu kanonicznego adresu: rozwiązuje ono kanoniczny adres i oznacza taki, który wskazuje na inny host, czyli dokładnie to, jak wygląda kanoniczny adres staging. Następnie sprawdź, czy problem dotyczy jednej strony, czy jednego layoutu, patrząc na wszystkie naraz. Darmowe narzędzie do crawlowania strony przechodzi po witrynie i raportuje status kanonicznego adresu dla każdego URL-a, obok flag noindex i zduplikowanych treści, które zwykle towarzyszą złemu wdrożeniu. Żeby wyłapać kolejny taki przypadek w dniu, w którym trafi na produkcję, włącz opcję Indexability na monitorze HTTP dla swoich kluczowych stron: odczytuje ona kanoniczny adres przy każdej kontroli i wysyła powiadomienie, gdy się zmieni. Monitoring SEO opisuje, jak to działa.