Webová stránka má spoustu součástí, které mohou ovlivnit další součásti a někdy se malé změny v těchto součástech mohou stát velkým problémem pro celou stránku.
Spousta toho, co je napsáno o technické optimalizaci internetových vyhledávačů je jen čistá teorie: ve scénáři ideálního světa, kde by webové stránky měly interagovat s procházeči internetových vyhledávačů a se systémy indexování.
V tom skutečném světě je to všechno ale úplně naopak. Webové stránky nejsou vůbec čistými systémy dodání obsahu, internetové vyhledávače nejsou vůbec neomylní předáci s umělou inteligencí a lidé, kteří kódují webové stránky, dělají spoustu neúmyslných chyb.
Za těch několik let jsme analyzovali nespočet webových stránek pro technické SEO problémy a také jsme se setkali s nespočtem problémů, které nebyly lehce vysvětlitelné jenom čistou SEO teorií. Namísto toho jsou tyto problémy takové, které vyžadují praktický přístup k vyřešení a někdy se samotný zdroj problému ani nepodaří vysvětlit a je ponechán svému osudu.
Tady bychom vám chtěli vyčíst hned několik problémů a snad vám dáme hned několik nápadů, jak byste je měli opravit a nakládat s nimi vy sami, pokud by se vám někdy v budoucnu náhodou stalo, že byste se s nimi museli potýkat.
Strukturovaná data a bohaté vybrané příspěvky
Jeden z našich klientů nedávno migroval jejich webovou stránku na novou technologii, která byla, ve všech ohledech, rychleji a lépe optimalizována než ta předchozí verze jejich webové stránky. Ale ještě před migrací si klient užíval bohatých vybraných příspěvků ve výsledcích vyhledávání Google. Více specificky – měli hvězdičkově hodnocené vybrané příspěvky na většině jejich klíčových stránek.
Ale po migraci velmi rychle ztratili všechna svá hvězdičková hodnocení. A nemohli přijít na to, proč.
Nástroj Google SDTT – Structured data Testing tool – nenabídl žádné řešení. Strukturovaná data na této stránce byla všechna správně reorganizována nástojem a vše se zdálo být v perfektním stavu. Takže proč Google ignoroval tento stav a odstranil všechny hvězdičkově hodnocené vybrané příspěvky z klientovy stránky?
Rozhodli jsme se vyzkoušet něco, o čem jsme si mysleli, že neudělá žádný rozdíl, ale skončili jsme u toho, že jsme celý problém kompletně vyřešili: přesunuli jsme strukturovaná data vybraných příspěvků do < head > sekce zdrojového kódu stránky.
To sice nebylo žádnou změnou pro SDTT, protože to nijak neovlivnilo validitu markupu v žádném směru. Byla to spíše poslední možnost, abychom viděli, jestli nějak pořadí, ve kterém se věci objevovaly ve zdrojovém kódu HTML, ovlivňovaly způsob, jakým je Google zpracovával.
Nedlouho poté, co jsme provedli tuto změnu, se bohaté vybrané příspěvky na stránce opět začaly rychle objevovat. Během několika dnů, všechny ztracené vybrané příspěvky byly zpátky.
Pozice strukturovaných dat může udělat velký rozdíl v tom, jak je Google zpracovává.
Zatímco teoreticky by to nemělo vůbec nijak ovlivňovat, kde vlastně ten markup je – dokud je přítomný v surovém zdrojovém kódu HTML. V praxi by vybrané příspěvky měly být v < head > sekci a ne v < body > sekci.
Avšak na základě tohoto problému je našim doporučením to, abyste vždycky dávali markup strukturovaných dat do < head > sekce zdrojového kódu HTML stránky. Vypadá to, že to má za následek daleko lehčí zpracování strukturovaných dat Googlem a ještě to pomůže s vybranými příspěvky více našich klientů.
Hreflang meta-tagy a iframes
Setkali jsme se s podobným problémem docela nedávno. Klientova stránka měla implementovány hreflang meta-tagy na jejich domovské stránce, aby indikovali alternativní verze, které cílily na odlišné státy. Tyto hreflang tagy byly perfektně v pořádku a přítomné ve všech verzích domovské stránky, avšak Google naprosto selhal v jejich rozpoznání.
Klientovi vývojáři si trhali vlasy a snažili se přijít na to, co by mohlo zabraňovat Google zpracovávat tyto meta-tagy. Tagy byly normálně přítomny ve zdrojovém kódu HTML stránky v < head > sekci, tak jak by měly být a měly úplnou reciprocitu od všech ostatních domovských stránek. Neměl by tam být žádný problém s tagy.
A stejně je Google vůbec nenahlásil v Search COnsole a stejně zobrazoval tu špatnou verzi v mezinárodních výsledcích vyhledávání.
Když jsme byli najati klientem, jedna z prvních věcí, kterou jsme udělali, byla ta, že jsme porovnali zdrojový kód HTML stránky s tím kompletovaným DOM. Ten první byl hned to, co uvidíte, když kliknete na „zobrazit zdroj“ na stránce, a ten druhý byl to, co prohlížeč ukázal konečným uživatelům, když kód na straně klienta (jako je JavaScript) byl proveden.
A tady jsme vypozorovali něco velmi zajímavého – v surovém HTML kódu byl kousek JavaScriptu, který tak nějak seděl nad hreflang meta-tagy. Když byla stránka plně vykreslena a všechen kód z klientovy strany byl proveden, JavaScript vložil < iframe > na tu stránku.
Tento iframe poté seděl na meta-tagu. A to byl ten problém, jak se později ukázalo.
Víte, iframy nepatří na < head > sekci webové stránky. Podle oficiálních HTML5 standardů, iframy by měly existovat v < body > sekci stránky. Tím, že dáte iframe do té výše zmíněné sekce kódu stránky se vlastně příčíte oficiálním standardům W3C.
Když Google indexuje webové stránky, pokouší se tak nějak srovnat se všemi těmto standardními problémy. Je velmi vzácné najít webovou stránku, která by měla kompletně spokojený W3C kód. Naštěstí je HTML velmi tolerantní markup jazyk. Webové prohlížeče a internetové vyhledávače zvládnout většinu webových stránek dobře, i když tyto stránky mají nějaký špatný markup.
Avšak v tomto případě se to ukázalo jako nejvíce problematické a všechno to spočívá ve dvou stádiích procesu indexace Google. První stádium indexování je založeno na zdrojovém kódu HTML stránky a žádný skript na straně klienta není proveden, co se týče této části procesu indexace. Ale poté Google provede další stádium indexace stejné stránky, kde skripty na straně klienta jsou načteny a stránka je plně vykreslena tak, jak by ji vykreslil internetový prohlížeč.
Během tohoto druhého stádia indexování JavaScript v kódu HTML stránky, který tam seděl na těch meta-tags, byl proveden a tedy iframe byl vložen do samotného kódu stránky.
A jak jsme tak analyzovali tento problém, vzpomněli jsme si na nedávnou twitterovou konverzaci mezi Jamiem Alberico a John Muellerem z Google o přesně těchto iframech v head sekci na vykresleném kódu stránky.
Ve zkratce, iframy nepatří do head sekce kódu stránky, měly by být v body sekci stránky. Když Google vidí nějaký iframe v head sekci, myslí si, že head sekce skončila a že začala body sekce.
A na druhé straně, hreflang tagy fungují pouze, pokud existují v head sekci stránky. Každý hreflang tag v body sekci stránky je viděn jako neplatný a je tedy ignorován Googlem.
Vypadá to, že Google zpracoval meta tagy jako součást druhého kola indexování popsaného výše. To vytvořilo perfektní bouři pro našeho klienta, kde Google vykreslil stránku a iframe byl vložen do jejího kódu. To poté způsobilo to, že Google předčasně zpracoval zbytek kódu jako část body sekce a tedy ignoroval přítomnost hreflang tagů.
A znovu, jakmile jsme našli níže popsaný problém, řešení bylo jednoduché. Přesunuli jsme poškozující JavaScript na konec head sekce, kde by vložení iframe nijak neškodilo.
A během několika dnů, Google rozpoznal hreflang tagy stránky a začal hlásit jejich přítomnost v Google Search Console.
Googlebot a automatické redirekty IP
Několik let zpátky jsme se setkali s problémem, který nás v té době opravdu zmátl. Klient nedávno spustil novou verzi jejich stránky a jako část jejich strategie expanze byla ta, že měly různé verze stránky pro jednotlivé státy, jedna mířila na USA, druhá na Velkou Británii a ten zbytek na, očividně, zbytek světa.
Americká verze této stránky velmi rychle začala s hodnocením a zdálo se, že pracuje dobře. Ale ta britská verze a verze pro zbytek světa dostávaly horkotěžko nějaký provoz z Google. Historicky byla Británie tím největším obecenstvem a nejvíce klientů měl klient právě zde a tato stránka byla velmi špatně výkonná na anglickém trhu.
Dívali jsme se na data ve Webmaster Tools a vůbec nám to nepomohlo. Tohle bylo ještě dávno předtím, než jej Google přejmenoval na Search Console a dal nám více užitečných dat. V té době vše, na co jsme mohli jít, bylo hlášení statusu indexu, který ukazoval docela nízké číslo indexovaných stránek. Hlášení sitemaps také moc nepomohlo – také jsme se rozhodli prozkoumat jednu XML sitemapu, která obsahovala všechny stránky a také tam jsme viděli jenom nízkou úroveň indexace, aniž by tam byla nějaká reálná nápověda, co vlastně způsobuje tento problém.
Za týden či dva po spuštění stránky se jeden z nás vzbudil uprostřed noci s momentem prozření. Najednou jsme věděli, co bylo jádrem toho problému.
Víte, tato nová stránka byla automaticky redirektována na základě uživatelovi IP adresy. Stránka by rozhodla, se kterou zemí byla IP adresa spojena a poté automaticky redirektovala návštěvníka na tu správnou verzi obsahu stránky.
Když ale GoogleBot prochází stránku, dělá to hlavně z IP adres, které jsou v USA. Velmi zřídka, pokud vůbec někdy, prochází stránky z mezinárodních IP adres.
Protože automatické redirekty stránky byly přítomné na všech stránkách, každý pokus prohlédnout si stránku, který nebyl harmonizován s vaší zemí, znamenal, že byste byli redirektováni na tu správnou verzi vaší země.
Pro GoogleBota to znamenalo to, že nemohl vidět žádné další sekce této stránky kromě té americké.
Kdykoliv se Googlebot snažil procházet po stránkách pro Velkou Británii a zbytek světa, byl by redirektován samotnou stránkou do té americké sekce. Takže zatímco GoogleBot úplně přesně a čistě viděl americké stránky, neviděl, a tedy nemohl indexovat ty ostatní sekce webové stránky.
Jakmile jsme pochopili tento problém, řešení bylo opět jednoduché – změnili jsme redirekty dle IP adresy a dali jsme tam výjimky pro návštěvy GoogleBota. Takto nemohl být GoogleBot redirektován do nějaké specifické země a mohl tak jednoduše a volně procházet celou webovou stránku.
Poté, co jsme provedli tuto změnu, úroveň indexování na stránce se masivně zlepšila a pro VB sekci se podařilo získat hodně provozu z Google v docela krátkém časovém úseku, takže se stránka vrátila na úroveň před migrací.
Technické SEO ve skutečném světě
Doufali jsme, že vám tyto příklady ukáží, že ve skutečném světě, technické SEO problémy mohou být velmi těžké na rozpoznání a identifikování. Webová stránka má spoustu pohyblivých součástí, které mohou ovlivnit jedna druhou a někdy může malinká změna v těchto součástech ovlivnit ostatní a způsobit tak pořádný problém někde v samém jádru.
Když analyzujete stránku, nemusíte vždycky mít všechna data, která byste chtěli. Problém s IP redirektem, kupříkladu, mohl být velmi lehce identifikovatelný, pokud bychom měli odlišné XML sitemapy pro jednotlivé verze států, ale to jsme holt neměli, tak jsme museli vyjít s tím, co jsme zrovna měli po ruce.
Chce to hodně dobré chápání SEO obecně a technické SEO zvláště, abyste byli schopni identifikovat, analyzovat a spravit takové problémy. Mít dobré chápání toho, jak vlastně prochází a indexují procházeče internetových vyhledávačů stránky, je tou základní znalostí = to je také jádrem celého technického SEO.
