Lühike vastus
Duplikaatsisu tähendab, et mitu URL-i annavad sama või peaaegu sama sisu. Karistust selle eest ei ole: Google ütleb, et veebilehe sisesed duplikaadid on tehniline olukord, mitte rikkumine. Probleem on mujal — otsingumootor peab ise otsustama, millist aadressi otsingutulemustes näidata, ja valik ei lange alati sellele, mida te turundasite.
Tavalisel veebilehel ei teki valdav enamik duplikaate kopeeritud tekstist, vaid sellest, kuidas sisuhaldussüsteem aadresse moodustab: kaldkriips lõpus, www, http, UTM-märgendid, sortimisparameetrid, toode kahes kategoorias. Ravi on kolm tööriista — 301-ümbersuunamine, canonical ja noindex — ning valik sõltub sellest, kas teine URL on elavale kasutajale vajalik.
Kust duplikaadid tegelikult tulevad
Kui klient ütleb «meil on duplikaadid», mõtleb ta tavaliselt kopeeritud teksti. Eesti saitidega töötades olen kopeeritud tootekirjeldusi kohanud tunduvalt harvemini kui tehnilisi duplikaate. Allikad selles järjekorras, kui sageli ma neid näen:
| Duplikaadi allikas | Näide | Tavaline põhjus |
|---|---|---|
| Ühe aadressi variandid | /teenused ja /teenused/, www ja ilma, http ja https | Serveri tasemel pole ühtset URL-i formaati |
| GET-parameetrid | ?utm_source=, ?sort=price, ?sessionid= | Reklaamimärgendid ja kataloogi sisemised funktsioonid |
| Toode mitmes kategoorias | /lambid/laualamp ja /kontorisse/laualamp | CMS moodustab URL-i kategooria teekonna järgi |
| Filtrid ja fassettnavigatsioon | ?color=black&size=xl mis tahes kombinatsioonis | Kataloog vastab koodiga 200 igale parameetrikombinatsioonile |
| Tehnilised koopiad | prindiversioon, AMP-jäänused, /index.php | Vanade mallide ja kolimiste pärand |
| CMS-i automaatsed lehed | kuupäeva-, sildi- ja autoriarhiivid, WordPressi manuselehed | Vaikimisi sisse lülitatud, keegi ei ole välja lülitanud |
| Ühesugused tekstid eri lehtedel | mallipõhised esinduste või linnade kirjeldused | Maandumislehtede masstootmine ilma unikaalse sisuta |
Oluline järeldus: duplikaadid tulevad peaaegu alati klasside kaupa, mitte ükshaaval. Kui leidsite ühe toote, mis avaneb kahelt aadressilt, siis avaneb kahelt aadressilt kogu kataloog. Seepärast otsin ma duplikaadi leides esimesena reeglit, mis selle tekitas, mitte ei paranda konkreetset lehte.
Eraldi tasub eristada duplikaate ja märksõnade kannibaliseerimist. Duplikaat on sama sisu erinevatel aadressidel. Kannibaliseerimine on erineva sisuga lehed, mis konkureerivad sama päringu pärast. Esimest ravitakse kokkuliitmisega, teist struktuuri ja sisu ümbertegemisega.
Millega duplikaadid päriselt kahju teevad
Kolm mõju, väga erineva suurusega.
Google näitab vale URL-i. See on peamine. Otsingumootor valib kanoonilise aadressi ise, arvestades linke, sitemap'i, canonical'it ja sisemist seotust. Kui signaalid on vastuolulised, võib otsingusse sattuda UTM-märgendiga aadress või toode teisejärgulisest kategooriast. Väliselt tundub liiklus olevat olemas, kuid kogutud signaalid on aadresside vahel laiali.
Raisku läheb roomamiseelarve. Kuni mõne tuhande lehega saidil pole see tavaliselt probleem — Googlebot jõuab kõike läbi käia. Kataloogis, kus filtrid tekitavad kümneid tuhandeid kombinatsioone, muutub olukord: robot kulutab käigud prügiaadressidele ja uued tootelehed ootavad indekseerimist nädalaid. Sümptomid kattuvad nendega, mida kirjeldasin artiklis sellest, miks Google lehti ei indekseeri.
Sisemine kaal hajub. Kui osa sisemisi linke viib aadressile /teenused ja osa aadressile /teenused/, jaguneb kaal ühe asemel kahe aadressi vahel. Mõju on kahest eelmisest tagasihoidlikum, kuid see kaob tasuta, kui linkimine korda teha.
Mida duplikaadid ei tee — need ei langeta kogu veebilehte. Kui teile öeldakse, et sait on «duplikaatide eest filtri all», paluge näidata konkreetset aruannet. Valdaval enamikul juhtudest peitub selle sõnastuse taga tavaline positsioonide langus mõnel muul põhjusel.
Kuidas duplikaate leida: kolm allikat
Ükski allikas ei anna täielikku pilti, seepärast vaatan alati kõiki kolme.
1. Search Console, aruanne «Lehtede indekseerimine». Kõige ausam allikas: see ei näita, mida teie duplikaadiks peate, vaid mida peab duplikaadiks Google. Olulised staatused:
- «Duplikaat, kasutaja ei ole kanoonilist versiooni märkinud» — Google leidis ühesuguse sisu ja liitis aadressid ise kokku, sest canonical'it ei olnud.
- «Google valis teise kanoonilise URL-i kui kasutaja» — te panite canonical'i, aga Google ei nõustunud sellega. See on märk, et kas lehed on tegelikult erinevad või siis sisemised lingid ja sitemap räägivad teie canonical'ile vastu.
- «Ümbersuunamisega leht» suures koguses — sageli jälg sellest, et ümbersuunamised töötavad, kuid sisemised lingid viitavad ikka vanadele aadressidele.
2. Veebilehe roomamine. Käige sait läbi Screaming Frogi, Sitebulbi või mõne muu kraulriga ja sorteerige tulemus kolme välja järgi: title, H1 ja sisu räsi. Kattuvad title'id on kiireim duplikaadiklassi tunnus. Kontrollige eraldi, kas sait vastab koodiga 200 aadressile suvalise lisatud parameetriga: kui /teenused?foo=bar avaneb tavalise lehena, on teil potentsiaalselt lõputu arv duplikaate.
3. Otsingutulemused ise. Päring kujul site:teiedomeen.ee "tekstilõik jutumärkides" näitab, mitu aadressi Google selle tekstiga indeksis hoiab. Jäme tööriist, kuid see püüab kinni selle, mis aruannetesse ei jõudnud: vanad alamdomeenid, testkoopiad, lõpetamata kolimise jäänused.
Neljas allikas, mis ununeb, on sitemap.xml. Kui kaardil on parameetritega või ümbersuunavad aadressid, ütlete Google'ile oma kätega, et need URL-id on kanoonilised. Kuidas see peaks olema seadistatud, kirjeldasin artiklis sitemap.xml ja robots.txt seadistamisest.
Millega kokku liita: 301, canonical või noindex
Tööriista valib üks küsimus: kas teine URL on elavale kasutajale vajalik?
| Olukord | Tööriist | Miks |
|---|---|---|
| Vana aadress pärast struktuurimuutust | 301-ümbersuunamine | URL-i pole enam vaja, kaal antakse edasi, aadress kaob otsingust |
| Kaldkriips, www, http | 301 serveri tasemel | Üks kanooniline formaat kogu saidile |
| UTM-märgendid ja sortimisparameetrid | canonical puhtale URL-ile | Link peab töötama, aga indekseeruma ei pea |
| Toode kahes kategoorias | canonical põhiteekonnale | Mõlemad lehed on navigatsioonis vajalikud |
| Lehekülgede jaotus | canonical iseendale | Lehed 2+ sisaldavad teisi tooteid ega ole duplikaadid |
| Prindiversioon, PDF-koopia | canonical HTML-versioonile | Kasutajale vajalik, otsingule mitte |
| Ostukorv, konto, sisemine otsing | noindex | Leht on inimesele vajalik, otsingus kasutu |
| Täiesti kasutud automaatsed arhiivid | noindex ja seejärel eemaldamine | Väärtust pole kellelegi |
Kolm asja, mille juures näen regulaarselt vigu:
- Canonical on soovitus, mitte käsk. Google arvestab seda koos teiste signaalidega ja võib eirata. Kui panete canonical'i lehele A, aga kõik sisemised lingid ja sitemap viivad lehele B, võidab B. Signaalid peavad olema kooskõlas.
- Ärge sulgege duplikaate robots.txt kaudu. Robots.txt-s keelatud lehte robot ei laadi alla — seega ei näe ta seal ei canonical'it ega noindex'it. Aadress jääb indeksisse staatusega «indekseeritud, kuigi robots.txt blokeerib» ja kokkuliitmist ei toimu. Robots.txt on roomamise säästmiseks, mitte indeksist eemaldamiseks.
- Ärge kombineerige ühel lehel noindex'it ja canonical'it. See on vastuoluline juhis: canonical ütleb «anna signaalid edasi», noindex «viska mind välja». Valige üks.
Keeleversioonid ei ole duplikaadid
Eesti turul on see kõige kallim viga kogu loetelust, sest siin on peaaegu iga sait mitmekeelne.
Eesti-, vene- ja ingliskeelne versioon sisaldavad erinevat teksti ja on suunatud erinevatele auditooriumidele — definitsiooni järgi ei ole need duplikaadid. Isegi kui pildid, hinnad ja struktuur kattuvad. Hullem veel: canonical eestikeelselt versioonilt venekeelsele viskab eestikeelse lehe eestikeelsest otsingust täielikult välja ehk annab kogu kohaliku liikluse konkurendile.
Õige skeem on lihtne: igal keeleversioonil on canonical iseendale ja omavahel seotakse need hreflang'iga, kaasa arvatud viide iseendale. Selle märgistuse tüüpvigu ja kontrollimist kirjeldasin eraldi artiklis hreflang'i seadistamisest.
Eraldi juhtum on üks keel mitmel domeenil või alamdomeenil, näiteks .ee ja .com sama ingliskeelse tekstiga. Need on juba päris duplikaadid saitide vahel ja siin aitab kas domeenidevaheline canonical või sisu aus lahku ajamine.
Mida ma praktikas näen
Mõned tähelepanekud Eesti projektidelt, mis korduvad ikka ja jälle.
Kõige sagedasem duplikaat ei ole kataloogis, vaid avalehel. Sait avaneb korraga neljal aadressil: www-ga ja ilma, https ja http. See seadistatakse ühe korraga serveri või CDN-i tasemel ja sulgeb terve probleemiklassi enne, kui keegi jõuab tootelehti vaadata.
Teine sageduselt on parameetrid sisemistest funktsioonidest. Sortimine, toodete arv lehel, seansi identifikaator, vana filtri jäljed. Iga selline parameeter kahe- või kolmekordistab kataloogi aadresside arvu.
Pärast kolimist tekivad duplikaadid ka õigete ümbersuunamiste korral. Ümbersuunamised tehakse ära, aga sisemised lingid menüüs, artiklite tekstides ja sitemap'is jäävad vanaks. Formaalselt kõik töötab, tegelikult käib Googlebot ahelaid pidi ja saab vastuolulisi signaale. Kontroll on lihtne: pärast kolimist ei tohi kraul leida ühtegi sisemist linki aadressile, mis vastab koodiga 301.
Duplikaadid käivad tihti käsikäes orblehtedega. Mõlemad tulenevad sellest, et saidi tegelik struktuur ja see, mida CMS sellest arvab, on lahku läinud. Ühte klassi lahendades tasub kohe kontrollida ka teist — kuidas orblehti leida, kirjutasin artiklis siselinkideta lehtedest.
Aus rakenduspiir: kõik eelnev käib saitide kohta kuni mõnekümne tuhande URL-ini, millega ma kõige sagedamini töötan. Suurtel kauplemisplatvormidel muutub parameetrite haldus omaette inseneriülesandeks ja otsused tehakse kataloogi arhitektuuri, mitte CMS-i seadete tasemel.
Tegevuste järjekord
- Kontrollige, kas sait avaneb mitmes avalehe aadressivariandis, ja seadistage 301 ühele kanoonilisele formaadile.
- Avage Search Console'is aruanne «Lehtede indekseerimine» ja kirjutage välja lehed koopia ja võõra kanoonilise URL-i staatustega.
- Tehke roomamine ja rühmitage lehed kattuvate title'ite ja H1 järgi — nii on näha klassid, mitte üksikjuhtumid.
- Otsustage iga klassi puhul, kas teine URL on kasutajale vajalik, ja valige tööriist ülaltoodud tabeli järgi.
- Viige sisemised lingid ja sitemap.xml valitud kanooniliste aadressidega kooskõlla — see on pool efektist.
- Kontrollige, et keeleversioonid oleksid seotud hreflang'iga, mitte liidetud canonical'iga.
- Naaske 3–4 nädala pärast aruande «Lehtede indekseerimine» juurde ja vaadake, kas Google teie valikuga nõustus.
Viimane samm jäetakse kõige sagedamini vahele, kuigi just see on tulemuse kontroll: kui Google valib endiselt teise kanoonilise URL-i, on kuskil alles vastuoluline signaal. Kui õiged aadressid tuleb sisse ehitada juba uue saidi arhitektuuri, on see veebiarenduse tasemel ülesanne, mitte punktparandus.
