Google: Canonical kan ställas in med JavaScript – vad detta innebär för SEO och e-handel

Snabb påminnelse: vad är kanoniskt och varför finns det?

Kanonisering är den process genom vilken Google väljer den mest representativa URL:en för innehåll när det finns flera liknande eller identiska versioner av en sida. En kanonisk URL är denna "representativa" version som Google föredrar att visa i sökresultaten. 

Inom e-handel är dubbletter av webbadresser vanliga eftersom butiker genererar varianter och kombinationer:

• filtrering och sortering (URL-parametrar),
• paginering,
• produktvarianter (färg/storlek),
• kampanjparametrar (UTM),
• språkversioner,
• olika vägar till samma innehåll (kategori → produkt vs sökmotor → produkt).

När kanonisk kod är felaktigt inställd kan konsekvenserna bli smärtsamma:

• Google indexerar fel adresser (röra i indexet),
• signaler (länkar, auktoritet, beteendedata) distribueras över flera webbadresser,
• du slösar bort din genomsökningsbudget på dubbletter,
• synligheten för viktiga kategorier och produkter minskar.

 Vad sa Google exakt om att den kanoniska versionen ställts in i JS?

Budskapet är enkelt:

• Det är bäst att ställa in kanonisk i HTML (i "
• Om du inte kan detkan du ställa in den kanoniska koden via JavaScript – men gör det på ett sätt som gör den kanoniska koden konsekvent och entydig. 
• Kanonisering sker före och efter rendering, så att ha de kanoniska "i källkoden" och "efter rendering" överlappande är att skapa problem. 

Google betonar också en mycket praktisk regel: om den kanoniska adressen redan finns i HTML, bör JS inte ändra den till en annan adress. Och om det är omöjligt att infoga den kanoniska adressen i HTML, är det bättre att inte inkludera den där alls och bara lägga till den via JS (korrekt, i "). 

Varför är det riskabelt att "sätta kanoniskt efter rendering"?

Eftersom Google inte alltid ser din webbplats på samma sätt som en användare ser den i en webbläsare. Enkelt uttryckt finns det två "ögonblick":

• HTML före rendering (vad servern returnerar omedelbart),
• HTML efter rendering (det som skapas efter att JavaScript har körts).

Om kanoniskt visas endast efter rendering, då:

• du ökar ditt beroende av att Google renderar JS korrekt,
• du skapar utrymme för crossovers (olika kanoniska i källkoden, olika efter rendering),
• det är lättare att göra misstag i ramverk (t.ex. duplicerade<link rel=”canonical”> ” eller att sätta in den på fel ställe).

Google påminner uttryckligen om att kanonisk kod accepteras när den är i ", och med JS måste du "injicera" det korrekt. 

När är kanonisk i JS meningsfull i praktiken?

Det finns situationer där detta kan vara en rimlig kompromiss:

• SPA-applikation renderad på klientsidan, där genereringen av " på servern är det svårt,
• äldre CMS/plattform där du inte har full kontroll över mallen,
• dynamiska vyer, där det kanoniska beror på applikationens tillstånd (även om särskild försiktighet krävs här).

I onlinebutiker (särskilt headless frameworks) sätts den kanoniska gränsen ibland av bibliotek som Head Manager (t.ex. React Helmet, Next.js Head). Detta fungerar, men bara om en enda, konsekvent kanonisk gräns finns kvar efter rendering och det inte finns några motstridiga signaler.

Den viktigaste regeln: kanonisk konsistens "före" och "efter" rendering

Om du minns en sak från den här artikeln, låt det vara denna:

Skapa inte en situation där det kanoniska i HTML pekar på A och det kanoniska efter rendering pekar på B.

Google påpekar själva att kanonisering sker i olika steg, så "blandade signaler" minskar otvetydigheten och ökar risken för att algoritmen väljer en annan version. 

Inom e-handel sker en sådan övergång ofta genom:

• filter och sortering som genererar olika webbadresser,
• automatisk parameterbindning i JS,
• routingfel (t.ex. snedstreck/inget snedstreck),
• skillnader i kanoniska adresser mellan mobil- och datorversioner.

Steg för steg: hur man implementerar canonical settable i JS utan mins

Steg 1: Bestäm vad som ska vara kanoniskt (affärslogik)

Först, etablera reglerna. Exempel i en butik:

• produkten har en kanonisk URL till den "rena" URL:en utan kampanjparametrar,
• kategorin har en kanonisk till osorterad version,
• filtrera sidor: antingen kanoniska för baskategorin, eller (om filter är SEO-mässiga) kanoniska för en specifik kombination – men då måste det finnas en indexeringsstrategi.

Steg 2: se till att det finns en kanonisk efterrendering

Inte två, inte tre. En. I "Google påminner dig om att infoga kanoniska ord korrekt och i rätt avsnitt i dokumentet. 

Steg 3: Om du inte kan infoga den kanoniska koden i HTML, infoga den inte alls

Detta är en viktig nyans från Googles förtydligande: det är bättre att inte ha någon kanonisk kode i källkoden än att ha en annan än den du anger senare i JS. 

Steg 4: Testa i Google Search Console

Google rekommenderar att du testar din rendering och kanoniska sökresultat med verktyg som Search Console för att säkerställa att Google ser vad du försöker uppnå. URL-inspektion är användbar när det gäller kanonisering, eftersom den bland annat visar den kanoniska sökresultat du har angett och den kanoniska sökresultat som Google har valt. 

Steg 5: Övervaka "Google valde en annan kanonisk" delningsfilter

Om Google ofta väljer en annan kanonisk sökterm än den du anger är det ett tecken på att:

• innehållet är inte tillräckligt likt (algoritmen anser att det inte är en dubblett),
• signalerna är motsägelsefulla (intern länkning, omdirigeringar, webbplatskartor),
• kanonisk indikerar en URL av lägre kvalitet (t.ex. med fel, inget innehåll, med andra parametrar).

Google beskriver att även om man anger kanonisk kan algoritmen välja en annan version av olika anledningar, och det är värt att kontrollera om Googles val är vettigt ur ett funktionellt perspektiv. 

Vanliga e-handelsmisstag som bryter mot kanoniska standarder (särskilt med JS)

Duplicera kanonisk

Ramverket injicerar den kanoniska, och butiksplattformen lägger till den andra i mallen. Efter rendering har du två olika "<link rel=”canonical”> ”. Effekt: signalen blir oläslig.

Kanonisk uppsättning utanför<head>

Google betonar upprepade gånger att kanonisk bör vara i"Om den landar i ", ignoreras ibland. 

Kanoniska pekar på URL med parametrar

Oftast bör canonical peka på den "rena" versionen. Om canonical pekar på en URL med UTM, sortering eller filtrering skapar du snabbt en labyrint.

Kanonisk beror på applikationens tillstånd

Användaren klickade på ett filter och JS ändrade det kanoniska. Som ett resultat kan roboten se olika versioner i olika renderingspass. Detta är svårt att kontrollera, och risken för indexeringskaos ökar.

Vad förändrar detta i praktiken för nätbutiker?

Om du driver ett e-handelsföretag har Googles förfining två verkliga effekter:

• Mindre rädsla i headless/SPA-projekt – canonical i JS kan fungera när det implementeras konsekvent. 
• Mer ansvar på implementeringssidan – eftersom "bästa praxis" fortfarande är kanonisk i HTML, och JS är en reservvariant. 

I butiker som har många URL-kombinationer (filter, parametrar, varianter) är kanonisering ett av de viktigaste verktygen för att organisera indexet. En välkonfigurerad kanonisering stöder synlighet för kategori och produkt, medan en felaktigt inställd kan hämma tillväxt.

Checklista: Vad du bör kontrollera i din butik idag 

• Öppna produktkortet och kontrollera i sidkällan om kanonisk är i ".
• Kontrollera om det fortfarande bara finns en kanonisk efterrendering (t.ex. i utvecklingsverktygen).
• Gå till URL:en med parametrar (UTM / sortering) och se om den kanoniska länken länkar till basversionen.
• I Search Console, använd URL-inspektion och jämför: deklarerad kanonisk kontra kanonisk vald av Google. 
• Om den kanoniska koden är inställd i JS - kontrollera om det inte finns någon överlappning med HTML (eller om HTML inte har någon kanonisk kode alls, om JS ska ställa in den). 

Var finns swiatcyfrowy.pl här?

Om du vill se till att canonical, JS-rendering och indexering är korrekt inställda är det snabbaste sättet att göra detta vanligtvis genom en teknisk SEO-revision (med e-handelselement).

I den digitala världen kan man behandla detta ämne som en del av en större diagnos: snygga till indexeringen, eliminera dubbelarbete, förbättra synligheten för kategorier och produkter och strama åt SEO-funneln → produktkort → kupi.swia