Een canonical URL herstellen die naar staging wijst

Hoe het symptoom eruitziet

Elke pagina op de live site levert een canonical die een andere host noemt:

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

Search Console toont het als "Duplicate, Google chose different canonical than user", of als pagina's die wegvallen met een door de gebruiker verklaarde canonical op een host die u nooit heeft geverifieerd. Omdat de staginghost normaal onbereikbaar, wachtwoordbeveiligd of noindexed is, is er geen bestemming voor de consolidatie om op te landen, dus de live pagina's stoppen gewoon één hercrawl per keer met ranken. Niets geeft een 500 en geen enkele uptimecheck merkt het, wat het duur maakt.

Waar de verkeerde base-URL vandaan komt

• Een database hersteld vanuit staging. In WordPress dragen de optierijen siteurl en home de staginghostnaam mee naar productie, en elke gegenereerde URL volgt ze.
• Een omgevingsvariabele in de gedeployde build. Een site-URL ingebakken tijdens de build, dus de gecompileerde output draagt de waarde van staging, ongeacht wat de runtimeomgeving zegt.
• Een framework-standaardhost per omgeving geconfigureerd, waarbij de productieconfig nooit is bijgewerkt nadat die van staging werd ingesteld.
• Een hardgecodeerde absolute URL in een gedeelde layout of SEO-plugin-instelling, geschreven tijdens een migratie en nooit meer bekeken.
• Een gecachete pagina gebouwd op de verkeerde host. Een CDN of full-page-cache gevuld door een staging-build bedient verouderde HTML met de staging-canonical, lang nadat de config was gecorrigeerd.

Corrigeer de waarde, verwijder dan de hele klasse fouten

1. Corrigeer de opgeslagen base-URL voor productie, waar van de plekken hierboven ook van toepassing is. In WordPress zijn dat de twee optierijen plus elke absolute URL geschreven in postcontent door de staging-kopie.
2. Herbouw en herdeploy als de waarde is ingecompileerd. Een omgevingsvariabele wijzigen zonder een herbouw laat de oude waarde in de verzonden bundel staan.
3. Ruim elke cache in het pad op, applicatie, CDN en edge allemaal. Een gecorrigeerde origin achter een cache vol staging-HTML ziet er nog steeds ongerepareerd uit zolang de cache leeft.
4. Geef er de voorkeur aan de canonical af te leiden van de request-host boven het lezen van een opgeslagen constante. Een canonical gebouwd op de host die het verzoek bediende, kan niet fout zijn in de omgeving waarin hij werd bediend, wat de hele klasse fouten wegneemt in plaats van dit ene geval.
5. Houd staging op andere manieren buiten de index. HTTP-authenticatie of een IP-allowlist op de staginghost is wat het zou moeten beschermen, geen canonical, en geen noindex die met een configbestand kan meereizen.

Verifieer de oplossing op productie

Lees het antwoord, niet de template, want plugins, edge-workers en caches injecteren allemaal canonicals die niet in uw repository verschijnen:

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

Controleer dan meer dan één pagina. De canonical wordt door een template gegenereerd, dus de homepage goed hebben bewijst niets over productpagina's, gepagineerde listings of alles wat door een andere layout wordt gerenderd. In Search Console toont URL-inspectie de door de gebruiker verklaarde canonical naast degene die Google koos, en de twee die na een hercrawl overeenkomen is de bevestiging die telt. Die hercrawl duurt dagen, dus een gecorrigeerde canonical herstelt het verkeer niet dezelfde middag.

Voorkom dat het opnieuw wordt uitgeleverd

Twee beveiligingen kosten bijna niets. De eerste is een assertie bij deployment: haal na een release een handvol productie-URL's op en laat de deploy falen als een canonical een andere host dan de productiehost noemt. De tweede is achteraf blijven kijken, want de storing komt net zo makkelijk mee met een databaseherstel of een plugin-instelling als met een codedeploy. De HTTP-checks van HostTracker kunnen asserties uitvoeren tegen de responsbody en de headers, dus een geplande check kan zo worden gemaakt dat hij faalt wanneer de canonical-tag op een pagina niet is wat u verwacht, en die mislukking waarschuwt zoals elke andere.

Controleer elke template, niet één pagina

Begin met één getroffen URL in de gratis canonical-checker: hij herleidt de canonical en markeert er een die naar een andere host wijst, wat precies is hoe een staging-canonical eruitziet. Zie dan of het probleem één pagina of één layout is door ze allemaal tegelijk te bekijken. De gratis sitecrawltool loopt de site door en rapporteert een canonical-status per URL, samen met de noindex-vlaggen en dubbele bodies die meestal een slechte deploy begeleiden. Om de volgende de dag waarop hij wordt uitgeleverd te betrappen, zet u de optie Indexability aan op een HTTP-monitor voor uw belangrijkste pagina's: hij leest de canonical bij elke check en stuurt een melding wanneer die verandert. SEO-monitoring behandelt hoe dat werkt.