Oprava canonical URL mířící na staging

Jak příznak vypadá

Každá stránka na živém webu obsluhuje canonical pojmenovávající jiného hostitele:

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

Search Console to zobrazí jako "Duplicitní, Google zvolil jiný kanonický řetězec, než vybral uživatel", nebo jako stránky vypadávající z indexu s uživatelem deklarovaným canonical na hostiteli, který jste nikdy neověřili. Protože staging hostitel bývá běžně nedostupný, chráněný heslem nebo s noindex, konsolidace nemá kam přistát, takže živé stránky prostě přestávají, recrawl po recrawlu, dosahovat pozic ve výsledcích vyhledávání. Nic nevrací 500 a žádná kontrola dostupnosti si toho nevšimne, a právě proto je to nákladné.

Odkud se špatná base URL bere

• Databáze obnovená ze stagingu. Ve WordPressu přenesou řádky voleb siteurl a home staging hostname do produkce, a každá generovaná URL se jimi řídí.
• Proměnná prostředí v nasazeném buildu. URL webu zapečená při buildu, takže zkompilovaný výstup nese hodnotu ze stagingu bez ohledu na to, co říká běhové prostředí.
• Výchozí hostitel frameworku nastavený zvlášť pro každé prostředí, kde produkční konfigurace nikdy nebyla aktualizovaná po té stagingové.
• Napevno zapsaná absolutní URL ve sdíleném layoutu nebo nastavení SEO pluginu, zapsaná během migrace a nikdy znovu nezkontrolovaná.
• Cachovaná stránka postavená na špatném hostiteli. CDN nebo cache celé stránky naplněná buildem ze stagingu obsluhuje zastaralé HTML se staging canonical ještě dlouho po tom, co byla konfigurace opravena.

Opravte hodnotu, a pak odstraňte celou třídu chyby

1. Opravte uloženou base URL pro produkci, ať je problém v kterémkoli z míst výše. Ve WordPressu jde o oba řádky voleb plus jakékoli absolutní URL zapsané do obsahu příspěvků staging kopií.
2. Znovu sestavte a nasaďte, pokud je hodnota zakompilovaná. Změna proměnné prostředí bez nového buildu nechá starou hodnotu v odeslaném balíčku.
3. Vyprázdněte každou cache na cestě, aplikační, CDN i edge stejně. Opravený origin za cache plnou staging HTML vypadá dál nefunkčně, dokud cache žije.
4. Dávejte přednost odvození canonical z hostitele požadavku před čtením uložené konstanty. Canonical postavený z hostitele, který požadavek skutečně obsloužil, nemůže být v prostředí, ze kterého byl obsloužen, špatně, což odstraní celou třídu selhání, ne jen tento konkrétní případ.
5. Držte staging mimo index jinými prostředky. Staging hostitele by mělo chránit HTTP ověřování nebo seznam povolených IP, ne canonical, a ne noindex, který se může přenést s konfiguračním souborem.

Ověřte opravu na produkci

Čtěte odpověď, ne šablonu, protože pluginy, edge workery i cache vkládají canonical, které se ve vašem repozitáři vůbec neobjeví:

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

Pak zkontrolujte víc než jednu stránku. Canonical generuje šablona, takže správná domovská stránka nic neříká o produktových stránkách, stránkovaných výpisech ani o čemkoli vykresleném jiným layoutem. V Search Console URL Inspection ukáže uživatelem deklarovaný canonical vedle toho, který zvolil Google, a shoda obou po recrawlu je potvrzení, na kterém záleží. Takový recrawl trvá dny, takže opravený canonical nevrátí návštěvnost hned to odpoledne.

Zabraňte tomu, aby se to nasadilo znovu

Dvě pojistky stojí skoro nic. První je kontrola v okamžiku nasazení: po vydání stáhněte hrstku produkčních URL a nasazení nechte selhat, pokud kterýkoli canonical pojmenovává jiného hostitele než produkčního. Druhá je dál to sledovat i potom, protože selhání může dorazit stejně snadno s obnovou databáze nebo nastavením pluginu jako s nasazením kódu. HTTP kontroly HostTracker umí ověřovat proti tělu i hlavičkám odpovědi, takže naplánovanou kontrolu lze nastavit tak, aby selhala, když tag canonical na stránce neodpovídá tomu, co očekáváte, a takové selhání upozorní stejně jako jakékoli jiné.

Zkontrolujte každou šablonu, ne jednu stránku

Začněte jednou postiženou URL v bezplatné kontrole canonical: přeloží canonical a označí ten, který míří na jiného hostitele, což je přesně to, jak vypadá staging canonical. Pak zjistěte, jestli je problém na jedné stránce, nebo v celém layoutu tím, že se na všechny podíváte najednou. Bezplatný nástroj pro procházení webu web projde a nahlásí stav canonical pro každou URL, spolu s příznaky noindex a duplicitním obsahem, které obvykle špatné nasazení doprovázejí. Chcete-li příště zachytit problém v den, kdy se nasadí, zapněte volbu Indexability u HTTP monitoru pro vaše klíčové stránky: při každé kontrole přečte canonical a pošle upozornění, když se změní. Jak to funguje, popisuje SEO monitoring.