Proč škodí duplicitní URL adresy?
Duplicita vzniká v případě, když se na webu nachází stejný nebo velmi podobný obsah na více URL adresách. V praxi by si roboti vyhledávačů měli sami určit tu správnou URL adresu, kterou nabídnou uživatelům. Co když se bude jednat o zrovna tu URL, kterou se nepředstavujete vy? V některých případech se stává, že dojde k indexaci obou (nebo více) URL adres. Ve všech uvedených variantách to znamená jedinou věc, žádná z duplicitních URL nedosáhne také síly, aby uspěla proti konkurenčním adresám.
Možnosti řešení duplicitních URL
Než se pustíme do příkladu duplicitních URL adres, bylo by vhodné si rychle říct jak můžeme duplicity ošetřit. Máme k dispozici celkem 4 varianty.
1) 30x Přesměrování
Toto řešení je vhodné při základních duplicitách www vs. non-www atp. Setkáme se s ním také při migracích a změnách již zaindexovaných URL adres. Není ovšem vhodné na duplicty vznikající např. UTM parametry.
2) Kanonizace
Rel="canonical" využíváme zejména v případě duplicit vzniklých parametry (např. UTM). Nevýhodou tohoto řešení je, že canonical je pouze doporučení. Záleží pouze na robotech zda jej budou respektovat.
3) Meta robots noindex
Oproti canonicalu má výhodu, že se jedná o direktivní značku. Meta robots využíváme zejména tam, kde chceme aby robot následovat interní odkazy na dané stránce (nastavíme noindex, follow).
4) Zákaz procházení v robots.txt
Výhodou tohoto řešení je, že šetří crawl budet. Můžeme ošetřit situace, které souvisí s využívám filtrace.
Dobře, jaké máme základní možnosti víme, nyní se pojďme podívat jaké příklady duplicit na webech klientů řešíme.
Jaké jsou nejčastější duplicity?
1) Duplicity související s nastavením hostingu
Webová stránka může mít několik verzí - jedná se například o verzi s www a bez www, s lomítkem a bez lomítka na konci URL, s index.php a bez index.php. Všechny tyto varianty URL považuje Google za samostatné webové stránky, na kterých předpokládá unikátní obsah.
Obecně při řešení tohoto problému platí, že bychom se měli vyvarovat vícenásobným přesměrováním. Tedy, pokud je správná URL adresa https://www.domena.cz, a řešíme problém duplicity http a non-www verze, tak bychom měli z http://domena.cz přesměrovat přímo na https://www.domena.cz (ne přes přesměrování http:// -> https:// a následně non-www na www verzi.
Duplicita http:// vs. https://
Tento problém se začal objevovat zejména v období kdy Google začal tlačit na přechod na https. Hodně vývojářů správně neošetřilo 301 přesměrování existenci obou verzí. Nejjednoduší cesta jak tento problém ošetřit je přidáním pravidla do .htaccessu
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Duplicita www a non-www
Záleží čistě na vás jakou variantu URL zvolíte. Jedno je jisté, druhou variantu musíte na zvolenou přesměrovat buďto pomocí 301 přesměrování nebo správným nastavením CNAME záznamu v DNS.
Přesmětování na verzi s www
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]Přesměrování na verzi bez www
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]Duplicita s koncovým lomítkem a bez koncového lomítka
Podobný případ jako www a non-www duplicita. Lze vyřešit 301 přesměrováním.
Přesměrování na verzi s koncovým lomítkem
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]Přesměrování na verzi bez koncového lomítka
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]Duplicita s index.php a bez něj
Soubor index.php může nadělat trošku více nepořádku než ostatní příklady přesměrování. Při jeho ošetření musíme dát pozor aby nevznikl tzv. "redirect loop". Problém se hodně často objevoval u webu postavených na platformě Wordpress.
Odstranění index.php z URL adresy
RewriteEngine on
RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L]2) Duplicity spojené s parametry v URL
Tento problém se objevuje typicky zejména u e-shopů. V rámci jejich kategorií, výpisů produktů, špatně provedené filtrace nebo UTM parametrů. Výsledek je jediné, velké množství URL adres, které mohou, v extrémních případech, velmi negativně ovlivnit crawl budget (zjednodušeně se jedná o čas, který mají roboti vyhledávačů vyhrazený na procházení URL adres vašeho webu).
Existuje několik možných řešení dané situace:
Kanonizace
V případě UTM parametrů se nabízí možnost využití kanonizace. Osobně bych vám pro všechny stránky webu doporučil používat sel-refencing canonical. Velmi dobře sepsaný článek popisující tuto problematiku najdete např. na blogu Pavla Ungra.
Řešení větších množství duplicit kanonizací ovšem není úplně ideální. Je k tomu hned několik důvodů. Pro Google není kanonizace direktivní, jedná se o pouhé doporučení, které může a nemusí respektovat. Aby robot zjistil, že je na dané url použitý rel canonical, musí dojít k projití zdrojového kódu robotem. Jak již z předchozí věty vyplývá, neřeší kanonizace problém s crawl budgetem.
Zákaz procházení v robots.txt
Toto řešení je ideální pro některé typy parametrů a větší kombinace filtrů. Velkou výhodou ošetření přes robots.txt je skutečnost, že vůbec nedochází k procházení kódu stránky, která je pravidlem blokována. Šetříme tak crawl budget. Příkladem může být třeba zákaz procházení kategorií u kterých nastavíme nestandardní počet produktů na stránce nebo jiné řazení produktů
Disallow: /*?count=
Disallow: /*?order=3) Duplicity spojené se špatným návrh URL
Tento problém nastává zejména v případech špatně navržené struktury URL adres. V případě neoštření situace kdy je produkt zařezen ve více kategoriích může docházet k jeho vícenásobné indexaci. Proto je v těchto případech vhodné využívat krátké URL adresy produktů. Ať se na produkt dostanete z jakékoliv z jeho přiřazených kategorií, vždy bude jeho výsledná URL adresa stejná.
Závěrem?
Body výše jsou pouze základní ukázkou toho jak mohou vznikat duplicity. Osobně doporučuji se duplicitám věnovat, zbytečně vám tříští sílu jednotlivých vstupních stránek. Bohužel se jedná o natolik rozsáhlou problematiku, že finální nasazení úprav doporučuji konzultovat se specialistou.