Canonical URL praksē: kad izmantot self-canonical, 301 redirect vai citu canonical URL

Canonical URL izvēle nav tikai taga pievienošana lapas kodā. Vispirms jāizlemj, kādai lomai konkrētais URL turpmāk jākalpo. Ja URL ir savas lapas vēlamā versija, parasti izmanto self-canonical. Ja divas pieejamas adreses rāda vienādu vai ļoti līdzīgu saturu, viena var norādīt canonical uz otru. Ja vecajai vai liekajai adresei vairs nav jābūt pieejamai, pareizā izvēle parasti ir 301 pāradresācija. Savukārt atšķirīgam meklēšanas nolūkam paredzētas lapas jāsaglabā atsevišķas un ar self-canonical.

Šis modelis ir sākumpunkts, nevis automātiska formula:

•      URL ir vēlamā versija pats sev — self-canonical;
•      vienāds saturs paliek sasniedzams vairākās adresēs — iespējams, canonical uz izvēlēto URL;
•      vecais vai liekais URL vairs nav vajadzīgs — 301 pāradresācija uz atbilstošo adresi;
•      saturs apkalpo patstāvīgu meklēšanas nolūku — atsevišķs indeksējams URL ar self-canonical.

Izšķirošie jautājumi ir divi: vai lietotājam joprojām jāvar atvērt šo URL un vai tā saturs patiešām ir cita URL dublikāts vai ļoti tuvs variants. Tie palīdz nejaukt tehnisku kanonizāciju ar satura kanibalizācijas diagnostiku. Kanibalizācijas auditā vispirms noskaidro, vai lapas konkurē par vienu nolūku. Šeit uzdevums sākas vēlāk: ir zināma URL savstarpējā attiecība, un jāizvēlas pareizā tehniskā darbība.

Četras izvēles vienā lēmumu tabulā

Tabula neatrisina robežgadījumus viena pati. Piemēram, filtrēta kategorija var būt gan nevajadzīgs parametra dublikāts, gan vērtīga piezemēšanās lapa ar atsevišķu pieprasījumu. Pirms tehniskas darbības ir jānovērtē saturs, lietotāja ceļš un URL turpmākā funkcija.

Kad lapai vajadzīgs self-canonical?

Self-canonical nozīmē, ka lapas rel="canonical" norāda uz tās pašas lapas vēlamo absolūto URL. Tas palīdz skaidri nosaukt reprezentatīvo adresi arī tad, ja sistēma vēlāk rada izsekošanas parametrus, drukas skatu vai citas alternatīvas. Google savās vadlīnijās iesaka canonical elementu iekļaut arī pašā kanoniskajā lapā.

Self-canonical ir piemērots, ja:

•      URL atgriež 200 OK, ir indeksējams un paredzēts rādīšanai meklēšanas rezultātos;
•      lapas saturs un meklēšanas nolūks ir patstāvīgs;
•      tieši šī protokola, domēna, ceļa un beigu slīpsvītras versija ir vietnes standarts;
•      iekšējās saites, XML sitemap un valodu anotācijas izmanto to pašu adresi.

Piemēram, ja vēlamā produkta lapa ir https://example.com/produkti/modelis/, tās canonical norāde var būt:

<link rel="canonical" href="https://example.com/produkti/modelis/">

Self-canonical nepadara vāju vai nejauši dublētu lapu automātiski vērtīgu. Tas arī negarantē, ka Google izvēlēsies deklarēto adresi. Meklētājs salīdzina lapas un citus signālus, tādēļ pretrunīgas pāradresācijas, iekšējās saites vai sitemap ieraksti var novest pie citas izvēles.

Kad canonical drīkst norādīt uz citu URL?

Canonical uz citu adresi ir piemērots tad, ja alternatīvajam URL tehnisku vai lietojamības iemeslu dēļ jāpaliek atveramam, bet tā galvenais saturs dublē izvēlēto versiju. Tags nemaina pārlūka adresi un nepārvieto lietotāju. Tas paziņo, kuru no līdzīgajām adresēm vietne uzskata par reprezentatīvu.

Tipiski piemēri ir izsekošanas parametrs, tā paša satura drukas skats vai atsevišķā adresē pieejams ļoti līdzīgs variants. Arī ne-HTML failam, piemēram, PDF, canonical attiecību var norādīt HTTP Link galvenē, ja servera konfigurācija to ļauj.

Pirms šādas norādes pārbaudiet:

1. vai galvenais saturs abās adresēs ir vienāds vai ļoti līdzīgs;
2. vai mērķa URL atgriež derīgu lapu, nevis kļūdu vai vēl vienu pāradresāciju;
3. vai mērķa lapa ir indeksējama un pati norāda uz sevi;
4. vai alternatīvais URL tiešām jāsaglabā lietotājiem pieejams;
5. vai HTML un HTTP galvenē nav atšķirīgu canonical norāžu.

Canonical nav piemērots tikai tāpēc, ka divas lapas runā par līdzīgu tēmu. Kategorijas lapai, salīdzinājumam un detalizētai produkta lapai var būt kopīgi vārdi, bet atšķirīgas funkcijas. Ja viena no tām norāda canonical uz otru, meklētājs var ignorēt norādi vai apstrādāt vienu URL kā dublikātu, zaudējot tam paredzēto atsevišķo redzamību.

Kad canonical vietā jāizmanto 301 redirect?

301 pāradresācija ir pareizāka, ja vecais vai liekais URL ir pastāvīgi aizstāts un lietotājam vairs nav iemesla tajā palikt. Serveris atbild ar pāradresāciju, pārlūks atver mērķa adresi, bet meklētājs saņem stipru signālu par jauno vēlamo URL. Google iesaka servera puses pastāvīgu pāradresāciju, ja lapas adrese ir pastāvīgi mainīta.

301 parasti izvēlas, ja:

•      lapai mainīts ceļš vai slug;
•      veca lapa aizstāta ar tiešu, saturiski atbilstošu pēcteci;
•      tiek apvienoti patiesi līdzvērtīgi URL;
•      jānostiprina viena HTTP/HTTPS, www/non-www vai beigu slīpsvītras versija;
•      vietne vai tās sadaļa tiek pārcelta, saglabājot precīzu veco un jauno URL kartējumu.

Pāradresācijas mērķim ir jāatbild uz to pašu vajadzību. Desmitiem izņemtu produktu vai rakstu novirzīšana uz sākumlapu nav kvalitatīvs kartējums tikai tāpēc, ka sākumlapa darbojas. Ja līdzvērtīga aizvietotāja nav, jāizvērtē 404 vai 410, nevis jāizveido maldinoša 301 pāradresācija.

Praktiski pārbaudiet arī pāradresācijas ķēdes. Shēma A → B → C rada lieku soli; labāk ir A → C. Nedrīkst veidoties cilpa, un gala URL jāatgriež 200 OK ar self-canonical uz sevi. Ja izmaiņa ir īslaicīga, 301 nav automātiska izvēle: jāapsver situācijai atbilstoša pagaidu pāradresācija.

Kad diviem URL jāpaliek atsevišķi indeksējamiem?

Divus URL nevajag apvienot tikai kopīgas terminoloģijas dēļ. Tie var palikt atsevišķi, ja katrs sniedz patstāvīgu atbildi, apkalpo citu uzdevumu un lietotājam ir pamatots iemesls apmeklēt abas lapas.

Piemēram, “projektu vadības programmas salīdzinājums” un “kā ieviest projektu vadības sistēmu komandā” ir saistītas tēmas, taču pirmajā gadījumā lietotājs izvēlas risinājumu, otrajā — plāno ieviešanu. Abām lapām var būt self-canonical, atšķirīgs virsraksts un savs iekšējo saišu konteksts.

Šeit jānošķir tehniskais un satura lēmums. Ja nav skaidrs, vai nolūki pārklājas, vispirms vajadzīgs satura audits. Canonical tags nav drošs aizstājējs lēmumam par lapu struktūru.

Kā rīkoties ar parametru URL?

Parametrs pats par sevi nenosaka risinājumu. Jāskatās, ko tas maina.

Izsekošanas parametri, piemēram, kampaņas marķieris, parasti nerada jaunu saturu. Ja šādam URL jāpaliek atveramam, tas var norādīt canonical uz tīro adresi. Līdzīgi var rīkoties ar kārtošanas parametru, ja mainās tikai produktu secība, nevis lapas galvenā nozīme.

Filtri ir sarežģītāki. Ja filtrētā kombinācija neveido atsevišķi vērtīgu lapu un var radīt ļoti daudz URL, jāplāno ne tikai canonical, bet arī pārmeklēšanas kontrole un iekšējo saišu uzvedība. Google norāda, ka canonical ar laiku var samazināt nekanonisko fasetētās navigācijas URL pārmeklēšanu, taču ilgtermiņā tas var būt mazāk efektīvs par mērķtiecīgu URL telpas pārvaldību.

Ja konkrēts filtrs veido stabilu, pieprasītu un saturiski pilnvērtīgu kategoriju, to var saglabāt indeksējamu ar self-canonical. Tad tam vajadzīgs konsekvents URL, unikāls ievads un jēgpilns produktu vai satura kopums. Nevajag visas parametru lapas akli kanonizēt uz kategorijas sakni, jo tā var paslēpt noderīgas atšķirības. Tāpat robots.txt nav canonical aizstājējs: bloķējot pārmeklēšanu, meklētājs nevar izlasīt lapas canonical elementu.

HTTP/HTTPS, www un beigu slīpsvītras varianti

Protokola un resursdatora varianti nav jāatstāj kā paralēla izvēle. Nosakiet vienu vietnes standartu, piemēram, https://www.example.com/lapa/, un pārējos variantus pastāvīgi pāradresējiet tieši uz to:

•      http://example.com/lapa → https://www.example.com/lapa/;
•      https://example.com/lapa/ → https://www.example.com/lapa/;
•      https://www.example.com/lapa → https://www.example.com/lapa/.

Gala URL liek self-canonical uz sevi. To pašu versiju izmanto navigācijā, sitemap un hreflang. Ja serveris vienlaikus pāradresē uz vienu adresi, bet lapas canonical norāda atpakaļ uz citu, vietne pati rada konfliktu.

Beigu slīpsvītra nav jāvērtē pēc universāla “pareizi” vai “nepareizi”. Svarīga ir viena konsekventa izvēle un tas, lai abi varianti neatgrieztu indeksējamas lapas ar pretrunīgiem signāliem.

Kas notiek, ja canonical un redirect signāli konfliktē?

Pāradresācija, rel="canonical", sitemap, iekšējās saites un hreflang kopā veido priekšstatu par vēlamo URL. Google raksturo pāradresāciju un canonical anotāciju kā stiprus signālus, bet sitemap — kā vājāku. Vairāki vienā virzienā vērsti signāli palielina izvēles skaidrību; pretrunas to samazina.

Tipisks konflikts ir šāds: URL A ar 301 ved uz B, bet B canonical norāda uz A. Cits variants — sitemap satur A, iekšējās saites ved uz B, savukārt B canonical norāda uz C. Šādā situācijā nav jēgas pievienot vēl vienu tagu. Jāsakārto viens gala URL un visi kontrolējamie signāli jāvirza uz to.

Jāizvairās arī no canonical ķēdēm. Ja A norāda uz B un B uz C, A labāk jānorāda tieši uz C. Vienā HTML lapā nedrīkst būt vairākas savstarpēji atšķirīgas canonical norādes. JavaScript nedrīkst mainīt servera atdotajā HTML definēto vēlamo URL uz citu adresi.

Kad ir pieļaujams cross-domain canonical?

RFC 6596 pieļauj canonical mērķi citā domēnā. Praktisks gadījums var būt kontrolēts viena un tā paša vai ļoti līdzīga materiāla izvietojums divās vietnēs, kad kopijai jāpaliek pieejamai, bet viena puse ir noteikta par vēlamo avotu. Abām pusēm jāvienojas par precīzu URL kartējumu, un mērķa lapai jābūt sasniedzamai un saturiski atbilstošai.

Tomēr cross-domain canonical nav droša pavēle meklētājam. Google var izvēlēties citu kanonisko URL. Turklāt Google vairs neiesaka šo metodi kā vispārēju risinājumu sindicēta satura partneriem, jo partneru lapas bieži nav pietiekami līdzīgas. Ja domēns vai lapa ir pastāvīgi pārcelta un vecajai adresei nav jāpaliek pieejamai, priekšroka dodama precīzai 301 pāradresācijai.

Kāpēc Google var ignorēt deklarēto canonical?

Google izvēlas kanonisko URL, nevis bez nosacījumiem izpilda vietnes norādi. Biežākie iemesli, kāpēc izvēle atšķiras, ir pārbaudāmi:

•      avota un mērķa lapas nav pietiekami līdzīgas;
•      mērķis atgriež 404, soft 404, pāradresāciju vai nav indeksējams;
•      HTML ir vairākas atšķirīgas canonical norādes;
•      elements atrodas dokumenta <body>, nevis derīgā <head>;
•      canonical, redirects, sitemap un iekšējās saites rāda dažādos virzienos;
•      absolūtajā URL ir kļūda, nepareizs protokols, resursdators vai ceļš;
•      valodu lapas tiek kanonizētas uz citas valodas versiju, lai gan katrai jābūt patstāvīgai;
•      servera HTML un pēc JavaScript izpildes iegūtais canonical nesakrīt.

Īpaši bīstama ir veidnes kļūda, kas visām lapām ieliek vienu un to pašu canonical. Tas var izskatīties tehniski korekti vienas lapas avota kodā, bet plašākā izlasē atklājas kā sistēmiska problēma.

Kā pārbaudīt canonical izvēli pēc ieviešanas?

Pārbaudei vajadzīgi gan tūlītēji tehniskie testi, gan dati pēc atkārtotas pārmeklēšanas.

1. Pārbaudiet HTTP atbildi. Vecajam URL jāatgriež paredzētais statuss un Location; kanoniskajam gala URL — 200 OK.
2. Apskatiet avota un renderēto HTML. Pārliecinieties, ka <head> ir viena canonical norāde ar precīzu absolūto adresi un JavaScript to nepārraksta.
3. Pārbaudiet signālu konsekvenci. Iekšējām saitēm, XML sitemap un tās pašas valodas hreflang klasterim jāizmanto vēlamais URL.
4. Testējiet abas adreses. Pārbaudiet gan alternatīvo, gan mērķa URL, ne tikai lapu, kura pārlūkā izskatās pareizi.
5. Izmantojiet Search Console URL Inspection. Indeksētās versijas datos salīdziniet “User-declared canonical” un “Google-selected canonical”. Live test palīdz pārbaudīt pieejamību un renderēto lapu, bet neprognozē Google galīgo canonical izvēli.
6. Dodiet sistēmām laiku un pārbaudiet vēlreiz. Canonical izvēle mainās pēc atkārtotas pārmeklēšanas un indeksēšanas, nevis obligāti uzreiz pēc izvietošanas.

Lielākā vietnē pārbaudei jāņem dažādi URL tipi: parametrs, pāradresēta lapa, kategorija, raksts, valodas versija un viens robežgadījums. Vienas sākumlapas veiksmīgs tests neapstiprina visas veidnes.

Īss kontrolsaraksts pirms izmaiņas

Pirms canonical vai 301 ieviešanas atbildiet uz šiem jautājumiem:

•      Vai URL pēc izmaiņas lietotājam joprojām jāatveras atsevišķi?
•      Vai avota un mērķa galvenais saturs ir vienāds vai ļoti līdzīgs?
•      Vai abām lapām tomēr ir atšķirīgs meklēšanas nolūks?
•      Vai izvēlētais mērķis ir tiešs, indeksējams 200 OK URL?
•      Vai pāradresācija ir pastāvīga, nevis īslaicīga?
•      Vai canonical, redirects, sitemap, iekšējās saites un hreflang sakrīt?
•      Vai parametru URL problēma ir indeksēšana, pārmeklēšanas apjoms vai abas?
•      Kā pēc ieviešanas tiks pārbaudīta Google izvēle?

Ja atbilde uz pirmo jautājumu ir “nē” un ir tiešs aizvietotājs, parasti izvēlas 301. Ja atbilde ir “jā” un saturs ir dublikāts, iespējams, der canonical uz citu URL. Ja lapa pati ir vēlamā versija, tai der self-canonical. Ja nolūks un vērtība ir atšķirīgi, URL saglabā atsevišķu. Robežgadījumos vispirms jāprecizē lapas funkcija, nevis jāmeklē tags, kas aizvietotu šo lēmumu.

Canonical URL kļūdas reti ir izolētas vienā koda rindā. Tās parasti rodas, kad vietnes arhitektūra, pāradresācijas, iekšējās saites un indeksēšanas norādes nav balstītas vienā URL modelī. Ja uzņēmumam vajadzīga palīdzība šā modeļa, tehnisko signālu vai ieviešanas pārbaudes izvērtēšanā, nākamais solis var būt profesionāls SEO un AI redzamības audits. Darbs sākas ar URL funkciju un lietotāja vajadzību, nevis ar iepriekš izvēlētu canonical vai pāradresācijas recepti.