Wat is een canonical URL, en wanneer gebruikt u er een

Wat rel=canonical daadwerkelijk doet

Dezelfde content is meestal op meer dan één URL bereikbaar. Trackingparameters, sessie-identificatoren, een schuine streep achteraan, http naast https, www naast het kale domein, een afdrukweergave, een gesorteerde lijst: elk daarvan is een aparte URL die dezelfde woorden bedient. Aan zijn lot overgelaten kiest een zoekmachine er zelf een, en misschien niet degene die u zou kiezen.

Een canonical is hoe u die keuze expliciet maakt:

<link rel="canonical" href="https://example.com/shoes">
Link: <https://example.com/shoes>; rel="canonical"

Twee eigenschappen zijn de moeite waard om u eigen te maken. Ten eerste is het een hint, geen instructie. Google weegt hem af tegen redirects, interne links, sitemap-vermeldingen en de content zelf, en kan en zal wel eens een andere canonical kiezen dan degene die u verklaarde. Ten tweede consolideert hij in plaats van te verwijderen. Signalen van het duplicaat komen ten goede aan de canonical, wat het verschil is met noindex, waar het duplicaat wat zoeken betreft simpelweg ophoudt te bestaan.

Zelfverwijzende canonicals

Elke indexeerbare pagina zou zichzelf als eigen canonical moeten verklaren. Het klinkt overbodig en het is de meest nuttige van de drie regels, omdat het parameters neutraliseert die u niet voorzag. Wanneer /shoes?utm_source=newsletter https://example.com/shoes verklaart, vouwt de campagne-URL automatisch samen met de schone in plaats van ermee te concurreren.

Drie regels om ze goed te krijgen: gebruik absolute URL's inclusief het schema, geef precies één canonical-element per pagina uit (een pagina met twee tegenstrijdige canonicals negeert ze allemaal), en houd de canonical consistent met de rest van uw signalen. Een canonical die naar een URL wijst die elders redirect, of die 404 teruggeeft, of die een noindex draagt, stuurt tegenstrijdige instructies en wordt gekort.

Cross-domain canonicals

Een canonical kan naar een ander domein wijzen. Dat is het juiste mechanisme wanneer u een artikel syndiceert naar een partnersite of een nieuwsaggregator: de kopie op hun domein verklaart uw URL als canonical, zodat de zoekrankings ten goede komen aan uw origineel in plaats van aan hun herpublicatie.

Het is ook wat canonicals gevaarlijk maakt. Niets houdt een pagina tegen om een URL te nomineren op een host waarmee ze geen relatie heeft, en niets aan de syntax laat een per ongeluk cross-domain canonical fout lijken. Hier komt de staging-storing vandaan.

De staging-canonical-storing

De meeste frameworks en content-managementsystemen bouwen de canonical door een geconfigureerde base-URL samen te voegen met het huidige pad. Die base-URL leeft in een omgevingsvariabele, een databaseoptierij of een configbestand, en is in elke omgeving anders. Wanneer de waarde van staging productie bereikt, verklaart elke pagina op de live site dat de echte versie leeft op https://staging.example.com/....

Wat volgt is stil en traag. De live pagina's blijven 200 teruggeven en blijven de juiste content bedienen. Maar elk van hen vertelt Google dat de gezaghebbende kopie ergens anders is, en die ergens anders is ofwel onbereikbaar, wachtwoordbeveiligd, of noindexed. Pagina's beginnen één hercrawl per keer uit de resultaten te vallen, en omdat er geen fout is om op te waarschuwen, is het eerste signaal meestal een verkeersgrafiek een week later. De reparatie staat in een canonical herstellen die naar staging wijst.

Canonical, redirect of noindex

De drie worden door elkaar gebruikt en zijn niet inwisselbaar:

• 301-redirect wanneer het duplicaat helemaal niet bereikbaar zou moeten zijn. Het sterkste beschikbare signaal, en het juiste antwoord voor een uitgefaseerde URL of een domeinverhuizing.
• rel=canonical wanneer beide URL's bereikbaar moeten blijven maar er maar een zou moeten ranken. Parameters, afdrukweergaves, gesyndiceerde kopieën, gefilterde lijsten.
• noindex wanneer de pagina bereikbaar moet blijven en niet mag ranken, en er geen equivalente pagina is om in te consolideren. Interne zoekresultaten, bedankpagina's, accountgebieden.

Stapel ze niet. Een canonical op een noindexed pagina is tegenstrijdig, aangezien u om consolidatie in een pagina vraagt en tegelijkertijd vraagt dat die relatie wordt genegeerd.

Verifieer wat u daadwerkelijk bedient

De template lezen is geen verificatie, want edge-workers, plugins en server-side logica injecteren allemaal canonicals die nooit in uw repository verschijnen. Lees in plaats daarvan het antwoord: curl -s https://example.com/ | grep -i 'rel="canonical"'. Voor één pagina herleidt de gratis canonical-checker de tag en zegt of die naar de pagina zelf wijst, een andere URL op dezelfde host, de http-versie of een andere host. Om de hele site te controleren rapporteert de gratis sitecrawltool een canonical-status per URL, en markeert de pagina's waar hij ontbreekt en de pagina's waar hij ergens anders naar wijst. Uw belangrijkste pagina's in de gaten houden voor de dag waarop de waarde verandert, is wat de optie Indexability op een HostTracker HTTP-monitor doet - zie SEO-monitoring.