Pradžia / SEO / Pasikartojančio turinio sprendimai

Pasikartojančio turinio sprendimai

Kodėl pasikartojantis turinys yra tikra galvos skausmas

Jei kada nors dirbai su didesniu svetainės projektu, tikriausiai žinai tą jausmą – sėdi, žiūri į Google Search Console ir matai, kad tavo puslapiai vienas kitą „ėda”. Arba dar blogiau: organinis srautas krenta, o tu net nesupranti kodėl, nes techniškai viskas atrodo tvarkoje. Pasikartojantis turinys – viena iš tų problemų, kuri gali tyliai kenkti mėnesius, kol pagaliau ją pastebėsi.

Techniškai kalbant, pasikartojantis turinys (angl. duplicate content) – tai situacija, kai tas pats arba labai panašus tekstas pasiekiamas keliomis skirtingomis URL adresais. Paieškos variklis tada atsiduria keblioje padėtyje: kurį puslapį rodyti paieškos rezultatuose? Kuriam priskirti nuorodų „svorį”? Dažnai sprendimas būna toks, kad nei vienas puslapis negauna tiek dėmesio, kiek galėtų.

Problema labiau paplitusi nei atrodo. Statistika rodo, kad net apie 29% viso interneto turinio yra vienaip ar kitaip pasikartojantis. Tai nereiškia, kad visi tie puslapiai yra sąmoningai nukopijuoti – dažniausiai tai techninis reiškinys, atsirandantis dėl CMS sistemų veikimo, URL parametrų ar netinkamos serverio konfigūracijos.

Kaip pasikartojantis turinys atsiranda – dažniausios priežastys

Prieš sprendžiant problemą, reikia suprasti, iš kur ji atsiranda. Ir čia dažnai nustembama – daugeliu atvejų tai ne žmogaus kaltė, o sistemos.

URL parametrai – viena iš labiausiai paplitusių priežasčių. Įsivaizduok el. parduotuvę, kurioje produktų filtrai generuoja naujus URL adresus:

  • example.com/batai
  • example.com/batai?spalva=juoda
  • example.com/batai?spalva=juoda&dydis=42
  • example.com/batai?sort=kaina

Visos šios URL rodo tą patį arba labai panašų turinį, tačiau paieškos varikliui jos atrodo kaip atskiri puslapiai. Jei svetainė turi tūkstančius produktų su dešimtimis filtrų kombinacijų – problema tampa milžiniška.

HTTP ir HTTPS versijos – klasika. Jei serveris neperadresuoja http:// į https://, techniškai egzistuoja dvi svetainės versijos. Tas pats galioja su www ir be wwwwww.example.com ir example.com turi būti ta pati svetainė, bet ne visada taip sukonfigūruota.

CMS generuojami puslapiai – WordPress, Magento, Drupal ir kitos sistemos dažnai automatiškai sukuria papildomus puslapius: archyvus pagal datą, kategorijų puslapius, žymų (tagų) puslapius, autorius. Visa tai gali tapti pasikartojančio turinio šaltiniu, ypač jei turinys yra panašus arba identiškas.

Sesijų ID URL adresuose – senesnės sistemos kartais prideda sesijos identifikatorių prie URL: example.com/puslapis?sessionid=abc123. Kiekvienas lankytojas gauna unikalų URL, tačiau turinys identiškas.

Spausdinimo versijos – kai kurios svetainės sukuria atskiras spausdinimui skirtas versijas (/print/ arba ?print=1), kurios yra beveik identiškos originalui.

Canonical žymė – pirmasis gynybos ratas

Canonical žymė (rel="canonical") – tai HTML elemento atributas, kuris paieškos varikliui nurodo, kuris puslapis yra „tikrasis” originalas. Tai tarsi pasakyti Google: „Žinau, kad šis turinys pasiekiamas keliais adresais, bet šis yra pagrindinis.”

Žymė dedama puslapio <head> sekcijoje:

<link rel="canonical" href="https://example.com/originalus-puslapis" />

Tai elegantiškas sprendimas daugeliu atvejų, ypač kai negali kontroliuoti URL struktūros arba kai turinys turi būti pasiekiamas keliais adresais dėl funkcinių priežasčių. Pavyzdžiui, el. parduotuvėje produktas gali būti keliose kategorijose – canonical žymė nurodo, kuris URL yra pagrindinis.

Tačiau canonical žymė nėra magiška lazdelė. Keletas dalykų, kuriuos reikia žinoti:

  • Google traktuoja ją kaip rekomendaciją, ne kaip privalomą direktyvą. Jei canonical nurodytas puslapis atrodo prastesnis (mažiau nuorodų, blogesnis turinys), Google gali ignoruoti žymę.
  • Canonical žymė turi būti absoliutus URL, ne santykinis.
  • Kiekvienas puslapis turėtų turėti canonical žymę – net jei ji nurodo į save patį (self-referencing canonical). Tai apsaugo nuo ateities problemų.
  • Canonical žymė neužkerta kelio puslapiui būti indeksuotam – ji tik nurodo prioritetą. Jei nori visiškai užblokuoti puslapį, reikia kitų priemonių.

301 peradresavimai – kai reikia tikro sprendimo

Jei canonical žymė yra „švelnusis” sprendimas, tai 301 peradresavimas – griežtasis. Kai puslapis peradresuojamas su 301 kodu, tai reiškia: „Šis puslapis persikėlė visam laikui.” Paieškos variklis supranta, kad turi konsoliduoti visą „svorį” į naują adresą ir nebeindeksuoti seno.

301 peradresavimai yra tinkamas pasirinkimas šiais atvejais:

  • Kai nori sujungti www ir be www versijas
  • Kai migruoji iš HTTP į HTTPS
  • Kai keiti URL struktūrą ir seni adresai nebereikalingi
  • Kai turi kelias domenų versijas (pvz., .lt ir .com), kurios rodo tą patį turinį

Techniškai peradresavimai konfigūruojami serverio lygmeniu. Apache serveriuose tai daroma per .htaccess failą:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx serveriuose:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Svarbu nepamiršti: peradresavimų grandinės (kai vienas peradresavimas veda į kitą, kuris veda į trečią) lėtina puslapio greitį ir silpnina nuorodų perdavimą. Idealiu atveju kiekvienas senas URL turėtų peradresuoti tiesiai į galutinį tikslą.

Robots.txt ir noindex – kada blokuoti, o kada ne

Kai kurie puslapiai tiesiog neturėtų būti indeksuojami. Čia į pagalbą ateina du įrankiai: robots.txt failas ir noindex meta žymė. Jie skirtingi ir svarbu suprasti, kada naudoti kurį.

Robots.txt – tai failas, esantis svetainės šaknyje (example.com/robots.txt), kuris nurodo paieškos robotams, kurių puslapių jie neturėtų lankyti. Pavyzdys:

User-agent: *
Disallow: /admin/
Disallow: /search?
Disallow: /cart/

Tačiau čia slypi dažna klaida: robots.txt blokuoja nuskanavimą (crawling), bet ne indeksavimą. Jei į užblokuotą puslapį veda nuorodos iš kitų svetainių, Google gali jį vis tiek įtraukti į indeksą – tiesiog be turinio. Todėl robots.txt nėra tinkamas įrankis pasikartojančiam turiniui spręsti.

Noindex meta žymė – tinkamesnis pasirinkimas, kai nori, kad puslapis nebūtų rodomas paieškos rezultatuose, bet robotas gali jį lankyti:

<meta name="robots" content="noindex, follow" />

Arba per HTTP antraštę:

X-Robots-Tag: noindex

Praktiškai: noindex gerai tinka puslapiams su URL parametrais (filtrai, rūšiavimas), paieškos rezultatų puslapiams, puslapiavimo puslapiams (2, 3, 4 puslapis ir t.t.), jei jų turinys nereikšmingas.

Vienas svarbus niuansas: jei puslapis yra blokuojamas robots.txt, Google negali perskaityti noindex žymės, nes negali apsilankyti puslapyje. Todėl šie du metodai neturėtų būti naudojami kartu tam pačiam puslapiui.

Turinio konsolidacija – strateginis požiūris

Kartais pasikartojančio turinio problema yra ne techninė, o strateginė. Tai atsitinka, kai svetainėje yra keli puslapiai, kurie kalba apie tą patį dalyką, bet yra pakankamai skirtingi, kad automatiniai įrankiai jų neaptiktų kaip duplikatų. Paieškos variklis vis tiek mato, kad jie konkuruoja tarpusavyje – tai vadinama keyword cannibalization.

Pavyzdžiui, jei turi tris straipsnius:

  • „Kaip pasirinkti nešiojamąjį kompiuterį”
  • „Geriausi nešiojamieji kompiuteriai 2024″
  • „Nešiojamojo kompiuterio pirkimo gidas”

Visi trys gali konkuruoti dėl tų pačių paieškos užklausų. Sprendimas – konsoliduoti. Sujunk juos į vieną išsamų straipsnį, peradresuok senus URL į naują, ir turėsi vieną stiprų puslapį vietoj trijų silpnų.

Prieš konsoliduojant, verta patikrinti Google Search Console, kurie puslapiai gauna srautą. Jei vienas iš trijų straipsnių jau gauna lankytojų, jis turėtų tapti pagrindiniu URL, į kurį peradresuojami kiti.

Turinio konsolidacija taip pat naudinga, kai svetainėje yra daug trumpų, mažai vertės teikiančių straipsnių. Vietoj dešimties 300 žodžių straipsnių apie susijusias temas – vienas 3000 žodžių išsamus gidas. Tai ne tik sprendžia pasikartojimo problemą, bet ir pagerina bendrą turinio kokybę.

Įrankiai, kurie padeda aptikti ir stebėti problemą

Teorija yra gerai, bet praktiškai reikia žinoti, kur ieškoti problemų. Laimei, yra nemažai įrankių, kurie gali automatizuoti šį procesą.

Google Search Console – pirmoji stotelė. Skiltyje „Coverage” (arba „Indexing” naujesnėje versijoje) matai, kurie puslapiai indeksuoti, kurie ne ir kodėl. Taip pat galima patikrinti, ar canonical žymės veikia kaip tikėtasi – naudok „URL Inspection” įrankį konkrečiam puslapiui patikrinti.

Screaming Frog SEO Spider – desktop programa, kuri nuskaituoja visą svetainę ir randa pasikartojantį turinį, trūkstamas canonical žymes, peradresavimų grandines ir daugybę kitų problemų. Nemokama versija leidžia nuskaityti iki 500 URL – dažnai pakanka mažesnėms svetainėms.

Ahrefs ir Semrush – mokamos platformos, kurios turi site audit funkcijas. Jos ne tik randa pasikartojantį turinį, bet ir parodo, kaip tai veikia organinį srautą. Semrush turi atskirą „Site Audit” modulį su konkrečiais pasikartojančio turinio ataskaitomis.

Siteliner – nemokamas įrankis, skirtas būtent pasikartojančiam turiniui aptikti. Parodo, kurie puslapiai turi daugiausiai pasikartojančio teksto ir kiek procentų turinio yra dubliuota.

Google Search operatoriai – paprastas, bet efektyvus metodas. Paimk unikalią frazę iš savo puslapio ir ieškok jos Google su kabutėmis: "unikali frazė iš puslapio". Jei paieška grąžina kelis rezultatus iš tavo svetainės – problema egzistuoja.

Praktinis patarimas: nekurk situacijos, kai naudoji visus įrankius vienu metu ir bandai spręsti visas rastas problemas iš karto. Pradėk nuo Google Search Console – tai nemokama ir tiesiogiai rodo, ką Google mato. Tada, jei reikia gilesnės analizės, imkis specializuotų įrankių.

Kai viskas sudėliota – kaip palaikyti tvarką ateityje

Pasikartojančio turinio problema nėra ta, kurią išsprendžiąs vieną kartą ir pamiršti. Svetainės auga, CMS sistemos atnaujinamos, nauji žmonės pradeda kurti turinį – ir problemos grįžta. Todėl svarbu sukurti procesus, kurie apsaugo nuo pasikartojimo ateityje.

Pirmiausia – turinio auditas turėtų tapti reguliaria praktika. Ne kiekvieną savaitę, bet bent kartą per ketvirtį verta peržiūrėti, ar neatsirado naujų problemų. Screaming Frog ar panašus įrankis gali būti sukonfigūruotas kaip automatinis nuskaitymas.

Antra – URL struktūros taisyklės. Jei komandoje yra keli žmonės, kurie kuria turinį ar valdo svetainę, reikia aiškių taisyklių: kaip formuojami URL adresai, kaip tvarkomi URL parametrai, kokie puslapiai gauna canonical žymes. Tai turėtų būti dokumentuota, ne laikoma kažkieno galvoje.

Trečia – CMS konfigūracija. Jei naudoji WordPress, įsidiek SEO įskiepį (Yoast SEO arba Rank Math) ir sukonfigūruok jį taip, kad automatiškai generuotų canonical žymes, valdytų archyvų indeksavimą ir blokuotų nereikalingus puslapius. Tai vieną kartą atliekamas darbas, kuris apsaugo nuo daugelio problemų.

Ketvirta – naujų funkcijų testavimas. Kai svetainėje diegiamos naujos funkcijos (filtrai, paieška, rūšiavimas), prieš paleidžiant į produkciją reikia patikrinti, ar jos negeneruoja naujų URL su pasikartojančiu turiniu. Tai lengviau padaryti iš anksto nei taisyti po to.

Galiausiai, verta suprasti, kad pasikartojantis turinys – tai ne bausmė, o natūrali interneto ekosistemos dalis. Net didžiausios svetainės turi šią problemą. Skirtumas tarp tų, kurioms tai kenkia, ir tų, kurioms ne – tai, ar problema valdoma, ar ignoruojama. Su tinkamais įrankiais, aiškia strategija ir reguliaria priežiūra pasikartojantis turinys tampa valdomu iššūkiu, o ne neišsprendžiama paslaptimi.