Kodėl dubliuotas turinys vis dar kelia galvos skausmą
Kai pradedi dirbti su SEO ar web projektais, anksčiau ar vėliau susiduri su duplicate content problema. Ir nors Google jau seniai tvirtina, kad už dubliuotą turinį nebaudžia (bent jau ne tiesiogiai), realybė yra kiek sudėtingesnė. Problema ne tiek bausmėje, kiek tame, kad paieškos sistema tiesiog nesupranta, kurią tavo puslapio versiją rodyti vartotojams.
Įsivaizduok situaciją: turi produkto aprašymą, kuris pasiekiamas per kelis URL. Google indeksuoja visus variantus, bet reitinguose rodo ne tą, kurį norėtum. Arba dar blogiau – tavo svetainės puslapiai konkuruoja tarpusavyje dėl tų pačių raktažodžių. Rezultatas? Jokia versija nepasieka aukštų pozicijų, nes „link juice” išsisklaido po visus dublikatus.
Problema ypač aktuali e-commerce svetainėms, kur tas pats produktas gali būti prieinamas per skirtingas kategorijas, su skirtingais filtrais, rūšiavimo parametrais. Turinys identiškas, bet URL skiriasi. Ir štai tau – dublikato problema ant lėkštės.
Kaip dubliuotas turinys atsiranda svetainėje
Dažniausiai duplicate content atsiranda ne dėl to, kad kažkas tyčia kopijuoja tekstus. Problema kyla iš techninių niuansų, kurių daugelis net nepastebi.
WWW vs ne-WWW versijos – klasikinis pavyzdys. Jei tavo svetainė pasiekiama ir per example.com, ir per www.example.com, tai jau du skirtingi URL su tuo pačiu turiniu. Serveris mato juos kaip atskirus puslapius, nors tau atrodo, kad tai tas pats dalykas.
HTTP ir HTTPS protokolai sukuria panašią problemą. Jei nesutvarkei tinkamų nukreipimų, svetainė gali būti pasiekiama abiem būdais. Ir vėl – dublikatas.
Trailing slash istorija irgi įdomi. URL /produktai ir /produktai/ techniškai yra skirtingi adresai. Dažnai serveris atiduoda tą patį turinį, bet Google mato kaip du puslapius.
Parametrai URL – čia jau rimtesnis dalykas. Ypač e-commerce projektuose. Filtrai, rūšiavimas, paginacija – visa tai generuoja naujus URL su tuo pačiu ar beveik tuo pačiu turiniu. Pavyzdžiui:
– /produktai?sort=price
– /produktai?sort=name
– /produktai?color=red&size=M
Mobilios versijos – jei dar naudoji atskirą m.example.com subdomeną mobiliajai versijai (nors šiais laikais tai jau retai praktikuojama), tai irgi potencialus dublikato šaltinis.
Printer-friendly puslapiai – senesnėse sistemose dar pasitaiko atskirų spausdinimui pritaikytų versijų, kurios dubliuoja pagrindinį turinį.
Vidinis vs išorinis dubliavimas
Reikia atskirti dvi skirtingas situacijas. Vidinis dubliavimas – kai problema tavo paties svetainėje. Tai valdoma, sprendžiama, kontroliuojama. Išorinis – kai kažkas nukopijavo tavo turinį į savo svetainę.
Su vidiniu dublikavimu dirbi tu pats. Čia tavo rankose serverio konfigūracija, CMS nustatymai, canonical tagų valdymas. Problemos kyla dažniausiai iš techninio neapdairumo ar sistemos ypatybių, bet sprendimas priklauso nuo tavęs.
Išorinis dubliavimas – kita istorija. Kažkas pasiėmė tavo tekstą ir publikavo savo svetainėje. Galbūt su nuoroda į tave, galbūt be. Čia jau reikia kitokių priemonių – nuo DMCA skundų iki tiesiog ignoravimo, jei matai, kad tai neturi įtakos tavo pozicijoms.
Įdomu tai, kad Google paprastai neblogai atpažįsta originalų šaltinį. Jei tavo svetainė turi geresnę reputaciją, seniau publikavo turinį ir turi stipresnį profilį, paieškos sistema supras, kas čia originalas. Bet pasitikėti vien tuo neverta – geriau imtis prevencinių priemonių.
Canonical tagų magija ir realybė
Canonical tag – tai HTML elementas, kuris nurodo paieškos sistemoms, kuri puslapio versija yra „tikroji”. Atrodo paprasta, bet praktikoje būna niuansų.
Sintaksė paprasta:
„`html
„`
Šį tagą įdedi į puslapio `
` sekciją ir teoriškai problema išspręsta. Google supranta, kad net jei šis turinys pasiekiamas per kelis URL, prioritetas turėtų būti teikiamas nurodytam adresui.Bet štai kur slypi pinkles. Canonical tag yra rekomendacija, ne direktyva. Google gali ją ignoruoti, jei mano, kad žino geriau. Pavyzdžiui, jei matai, kad vartotojai dažniau ieško ir paspaudžia ant kito URL varianto, paieškos sistema gali nuspręsti rodyti jį, nepaisant tavo canonical tago.
Kita problema – neteisingas naudojimas. Mačiau projektų, kur canonical tagą naudojo kaip 301 redirect pakaitalą. Tai neteisinga. Jei puslapis tikrai nebeaktualus ar perkeltas – naudok redirect. Canonical skirtas būtent dublikatų valdymui, kai abu puslapiai lieka aktyvūs.
Dar viena klaida – santykiniai vs absoliutūs URL. Nors Google teigia, kad abu variantai veikia, praktikoje geriau naudoti absoliučius URL su protokolu ir domenu. Taip išvengi galimų nesusipratimų.
E-commerce projektuose canonical tagus reikia naudoti ypač atidžiai. Jei turi produktą keliose kategorijose, pasirink vieną „pagrindinę” kategoriją ir visur kitur canonical nukreipk į ją. Pavyzdžiui, jei batai yra ir „Vyriški batai”, ir „Išpardavimas” kategorijose, nuspręsk, kuri versija yra prioritetinė.
301, 302 ir kiti redirect variantai
Kai canonical tago nepakanka arba jis netinka situacijai, ateina redirect’ų eilė. Čia svarbu suprasti skirtumą tarp įvairių tipų.
301 Moved Permanently – tai nuolatinis nukreipimas. Sakai paieškos sistemoms: „Šis puslapis perkėlė į naują adresą ir nebegrįš.” Google perduoda beveik visą SEO vertę (link equity) į naują URL. Naudok, kai tikrai nori, kad senas adresas išnyktų iš indekso.
302 Found (arba Temporary Redirect) – laikinas nukreipimas. Teoriškai skirtas situacijoms, kai puslapis laikinai nepasiekiamas, bet grįš. Praktikoje Google jau seniai elgiasi su 302 panašiai kaip su 301, bet vis tiek geriau nenaudoti jo ilgalaikiam sprendimui.
307 Temporary Redirect – naujesnis HTTP/1.1 standartas laikiniam nukreipimui. Garantuoja, kad HTTP metodas (GET, POST) išliks toks pat. Retai naudojamas SEO kontekste.
Kaip implementuoti? Priklauso nuo serverio. Apache .htaccess faile:
„`
Redirect 301 /senas-puslapis/ https://example.com/naujas-puslapis/
„`
Nginx konfigūracijoje:
„`
location /senas-puslapis/ {
return 301 https://example.com/naujas-puslapis/;
}
„`
Svarbu: redirect grandinės – blogai. Jei A nukreipia į B, o B į C – tai lėtina puslapio įkėlimą ir gali prarasti dalį SEO vertės. Visada nukreipk tiesiai į galutinį adresą.
Dar vienas niuansas – redirect loops. Kai A nukreipia į B, o B atgal į A. Atrodo akivaizdu, bet sudėtingose sistemose su keliomis taisyklėmis tai gali atsitikti. Rezultatas – puslapis visai neįsikrauna.
robots.txt ir meta robots direktyvos
Kartais nori tiesiog pasakyti Google: „Šito puslapio neindeksuok.” Tam yra kelios priemonės, ir svarbu suprasti, kada kurią naudoti.
robots.txt failas – tai instrukcijos paieškos robotams, kurias jie skaito prieš pradėdami skenuoti svetainę. Čia gali užblokuoti visus URL, kurie atitinka tam tikrą šabloną:
„`
User-agent: *
Disallow: /admin/
Disallow: /*?sort=
Disallow: /*?filter=
„`
Bet yra problema: robots.txt neleidžia robotui aplankyti puslapio, bet nebūtinai neleidžia jo indeksuoti. Jei į užblokuotą puslapį veda nuorodos iš kitų svetainių, Google gali jį įtraukti į indeksą (nors be turinio aprašymo).
Meta robots tag – tikslesnis įrankis. Jį įdedi į puslapio `
`:„`html
„`
Čia galimos kombinacijos:
– `noindex` – neindeksuok šio puslapio
– `nofollow` – nesek nuorodų šiame puslapyje
– `noindex, follow` – neindeksuok, bet sek nuorodas (dažniausias variantas dublikatams)
– `noindex, nofollow` – visiškas blokavimas
Svarbu: kad Google pamatytų meta robots tagą, jis turi galėti pasiekti puslapį. Todėl neblokuok robots.txt faile puslapių, kuriuos nori kontroliuoti per meta robots.
X-Robots-Tag HTTP header – alternatyva meta tagui, naudinga ne-HTML failams (PDF, vaizdam):
„`
X-Robots-Tag: noindex
„`
Konfigūruojama serverio lygmenyje.
Parametrų valdymas Google Search Console
Google Search Console (buvęs Webmaster Tools) turi įrankį URL parametrams valdyti. Tai naudinga, kai svetainėje yra daug URL su parametrais, kurie nekuria unikalaus turinio.
Eini į Search Console → Legacy tools and reports → URL Parameters. Ten gali nurodyti, kaip Google turėtų elgtis su konkrečiais parametrais:
– No URLs – Google neturėtų skenuoti URL su šiuo parametru
– Representative URL – Google pats pasirenka, kurį URL rodyti
– Every URL – kiekvienas URL unikalus, skenuok visus
Pavyzdžiui, jei turi `sessionid` parametrą, kuris nekuria unikalaus turinio, gali nurodyti „No URLs”. Jei `color` parametras rodo skirtingus produktus – „Every URL”.
Bet atsargiai! Neteisingi nustatymai gali išmesti iš indekso svarbius puslapius. Google pats rekomenduoja naudoti šį įrankį tik tada, kai tikrai supranti, ką darai. Dažniausiai geriau spręsti per canonical tagus ar robots.txt.
Dar vienas niuansas – šis įrankis veikia tik Google paieškai. Bing, Yandex ir kitos paieškos sistemos jo nemato. Todėl universalesni sprendimai (canonical, robots.txt) dažnai yra geresnis pasirinkimas.
Praktiniai patarimai skirtingoms situacijoms
Teorija teorija, bet kaip tai pritaikyti realiuose projektuose? Štai keletas konkrečių scenarijų ir sprendimų.
E-commerce svetainė su produktais keliose kategorijose:
Pasirink vieną „pagrindinę” kategoriją kiekvienam produktui (paprastai ta, kuri logiškai svarbiausia arba turi trumpesnį URL). Visose kitose kategorijose naudok canonical tagą, nukreipiantį į pagrindinę versiją. Alternatyviai – naudok noindex, follow meta tagą papildomose kategorijose, jei nori visiškai išvengti indeksavimo.
Filtrai ir rūšiavimas:
Dauguma filtrų ir rūšiavimo parinkčių turėtų būti užblokuotos robots.txt arba turėti canonical tagą, nukreipiantį į pagrindinį kategorijos puslapį be parametrų. Išimtis – jei konkretus filtras kuria tikrai vertingą, unikalų turinį (pvz., „raudoni vyriški batai” gali būti atskiras SEO taikinys).
Paginacija:
Čia nuomonės skiriasi. Vienas požiūris – naudoti canonical tagą visose puslapių numeracijose, nukreipiant į pirmą puslapį. Kitas – leisti indeksuoti visus puslapius, bet naudoti rel=”next” ir rel=”prev” tagus (nors Google oficialiai jų nebepalaiko nuo 2019). Trečias – naudoti „View All” puslapį su visu turiniu ir canonical į jį. Pasirinkimas priklauso nuo turinio kiekio ir svetainės specifikos.
WWW vs ne-WWW:
Pasirink vieną variantą ir nukreipk kitą per 301 redirect. Serverio lygmenyje. Paprastai tai daroma .htaccess arba Nginx konfigūracijoje. Pavyzdys Apache:
„`
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
„`
HTTP vs HTTPS:
Visada 301 redirect iš HTTP į HTTPS. Šiais laikais tai turėtų būti standartinė praktika. Papildomai naudok HSTS headerį, kad naršyklė automatiškai naudotų HTTPS.
Mobilios ir desktop versijos:
Jei dar naudoji atskiras versijas (m.example.com), naudok bidirectional canonical/alternate tagus. Desktop versijoje:
„`html
„`
Mobilioje versijoje:
„`html
„`
Bet geriausia – pereiti prie responsive dizaino ir išvengti šios problemos visai.
Kai dubliuotas turinys tampa strategija, o ne problema
Baigiant šią techninių sprendimų odisėją, verta pažvelgti į situaciją plačiau. Duplicate content problema dažnai kyla ne iš blogumo ar neapdairumo, o iš to, kad web projektai tiesiog sudėtingi. Turi balansą rasti tarp vartotojo patogumų (filtrai, rūšiavimas, įvairios prieigos prie to paties turinio) ir SEO optimizacijos.
Svarbiausia suprasti, kad nėra vieno universalaus sprendimo. Kiekvienas projektas unikalus. Mažam blog’ui pakanka paprastų canonical tagų ir teisingų nukreipimų. Didelei e-commerce platformai su šimtais tūkstančių produktų reikia sudėtingesnės strategijos – galbūt kombinuojant robots.txt taisykles, canonical tagus, noindex direktyvas ir Search Console parametrų valdymą.
Praktika rodo, kad geriausia pradėti nuo audito. Išsitraukk visus svetainės URL (galima naudoti Screaming Frog, Sitebulb ar panašius įrankius), identifikuok dublikatus, sugrupuok pagal tipus ir tada metodiškai spręsk kiekvieną grupę. Neveik chaotiškai – turėk planą.
Dar vienas svarbus dalykas – monitoringas. Duplicate content problema nėra „išsprendžiu kartą ir užmirštu”. Svetainė auga, keičiasi, atsiranda naujų funkcijų. Reguliariai tikrink Search Console, žiūrėk, kokie puslapiai indeksuojami, ar nėra netikėtų dublikatų. Automatizuok, kiek įmanoma – naudok įrankius, kurie praneš, jei atsiras naujų problemų.
Ir galiausiai – nesikrimsk per daug. Taip, duplicate content gali pakenkti SEO, bet tai ne katastrofa. Google nebaudžia už tai tiesiogiai (nebent kalba apie tyčinį, manipuliatyvų dubliavimą). Tiesiog neoptimaliai paskirsto tavo svetainės vertę. Spręsk problemas pagal prioritetus – pirma tuos dublikatus, kurie tikrai daro įtaką svarbiems puslapiams, paskui visus kitus.
Technologijos keičiasi, Google algoritmai tobulėja, bet pagrindiniai principai lieka tie patys: aiškus svetainės struktūra, logiškas URL architektūra, teisingas techninių įrankių naudojimas. Sutvarkyk šiuos pamatus, ir dubliuoto turinio problema nustos būti galvos skausmu, o taps tiesiog dar vienu aspektu, kurį kontroliuoji.