Zajímavé poznatky z první diskuze pro ČR s Johnem Muellerem z Google

Vydáno 25. listopadu 2016 na blogu SEO, SEO a PPC ve vyhledávačích

24. 11. 2016 proběhla první diskuze českých webmasterů a marketingových specialistů s Johnem Muellerem, který pracuje v Google na pozici Webmaster Trend Analyst. Za naši agenturu se diskuze v Googlu zúčastnil i Martin Šimko. Přečtěte si shrnutí zajímavých informací, které byly předmětem tohoto setkání.

John Mueller pravidelně odpovídá na dotazy webmasterů a odborníků z celého světa, diskuze zaměřená přímo na české specialisty tu však ještě nebyla. Za zorganizování děkujeme Pavlu Ungrovi, který akci uspořádal v rámci pravidelných setkání SEOloger.

V tomto příspěvku shrnuji zajímavé informace, které John během diskuze poskytl. Pokud se chcete podívat na celé video, je ke zhlédnutí na konci článku.

Co dělat, když se ve výsledcích vyhledávání neobjevují rich snippets, přestože technicky je implementace v pořádku?

Je potřeba, aby byl strukturovanými daty označen správný typ obsahu, např. aby klasický článek nebyl označen jako recept. Obsah, který je strukturovanými daty označený, musí být normální viditelnou součástí stránky. Pokud splňujete tato pravidla (krom klasických technických pravidel implementace), roboti jednoduše musí usoudit, že vaše stránka je dostatečně důvěryhodná a kvalitní. To není tak jednoduché rozpoznat.

Poznámka: Z mého pohledu je přirozené, že Google nezobrazí rich snippets u všech stránek. Podle mne to neznamená, že stránka, kde snippety nejsou, zákonitě není kvalitní. Můžete mít vedle sebe několik konkurenčních webů, které i např. z historického hlediska mají o něco lepší ukazatele kvality a důvěryhodnosti. Pak je jasné, že Google je pro zobrazení těchto prvků upřednostní. Dle mého názoru se také může stát, že si váš web skutečně rich snippety „zaslouží“, ale Google je nezobrazí. Buďme realističtí – posuzovaní robotů je automatizovaný komplikovaný proces a holt ne vždy to vyjde. 

Jak se Google staví k automatickému vytváření titulků a meta descriptions?

V případě velkých webů, které mají mnoho kategorií či produktových stránek, je naprosto v pořádku vytvářet titulky a meta popisy automatizovaně dle šablon. Není reálné, aby se u webu s několika tisíci stránek vytvářely tyto parametry ručně. John však nedoporučuje tento postup aplikovat na články či překlad textů.

Na co se bude Google zaměřovat v blízké budoucnosti?

John říká, že je potřeba řešit problémy, které lidé skutečně mají. Z jejich pohledu se to nyní týká hlavně mobilních přístupů a nepřizpůsobených stránek a bezpečnosti. Souhlasil, že trojice mobilní přizpůsobení (mobilní index), AMP (Accelerated Mobile Pages) a HTTPS protokol jsou záležitosti, na které se budou i v budoucnu hodně zaměřovat.

AMP – Accelerated Mobile Pages

John velmi doporučuje AMP implementovat na stránky s informačním typem obsahu. Upozorňuje, že v současnosti tato metoda zrychlení stránek mobilním uživatelům není dobře aplikovatelná na e-shopy, stránky s nutným přihlášením a interaktivní či personalizované typy obsahu. Pokud však máte blog či klasickou webovou prezentaci firmy a služeb, je dobré AMP zavést. John také upozorňuje, že AMP není hodnoticí faktor Googlu, může to být však přínosné pro uživatele, kvůli zrychlení načítání.

Poznámka: I na e-shopy je však možné tuto technologii aplikovat – eBayi se to povedlo – zde je příklad jejich AMP stránky. Je zajímavé, že dříve byly AMP doporučovány všem typům stránek. Myslím si, že John v naší diskuzi popisoval AMP z praktického hlediska a efektivity implementace. Podle mne je možné téměř všechny typy stránek na AMP převést, ale implementace je hodně náročná a v současnosti se pravděpodobně nevyplatí.

Je problém, pokud vedou spamové zpětné odkazy na dříve hackery napadenou stránku, která nyní vrací stavový kód 404?

Problém to není. Napadená stránka, na kterou vedou spamové zpětné odkazy, a která byla zrušena, nemůže nijak ohrozit další stránky webu. Je samozřejmě potřeba celkový problém napadení vyřešit a web zabezpečit.

Jaká je situace s porozuměním obsahu? Je možné, že s vyvíjející se znalostní bází a technologií, které dokážou lépe porozumět entitám v obsahu a souvislostem mezi nimi, půjdou např. off-page faktory – zpětné odkazy – jako hodnoticí faktor do pozadí?

Dotaz byl položen v návaznosti na tuto studii, kterou Google vydal.

Google s tímto porozuměním již pracuje, snaží se porozumět entitám, souvislostem a smyslu textu jak na stránkách, tak ve vyhledávacích dotazech uživatelů. To lze zpozorovat např. na tzv. featured snippets. John si ale nemyslí, že by tato technologie v dohledné době nahradila hodnoticí faktor zpětných odkazů. Google stále používá velké množství ukazatelů k posouzení stránky, které různě kombinuje. V praxi je tomu tak, že se ve výsledcích vyhledávání někdy umisťuje stránka s množstvím hodnotných zpětných odkazů, ale někdy naopak zde Google zobrazí stránku bez zpětných odkazů, jejíž obsah vyhodnotí jako kvalitní a přínosný.

Patenty a studie, které Google vydává

John upozorňuje na to, že vydání patentu ještě neznamená to, že patent budou v blízké době implementovat. V Google je spousta chytrých lidí, kteří vymýšlejí nové postupy a metody a vydáním patentu či studií se o ně dělí s ostatními. Není to ale tak, že by okamžitě po vydání patentu začali v Googlu pracovat na realizaci. Pokud tedy sledujete patenty, které Google vydává, berte je z hlediska praktického dopadu s rezervou.

Stránky 404 a soft 404

Lidé mohou být zmateni z reportu v Search Console, který neustále reportuje nové neexistující stránky. Je to ale v pořádku, je přirozené, že web má neexistující stránky. Dle Johna také nevadí, když jsou neexistující stránky v Sitemap.xml. Roboti je projdou a jednoduše vyřadí nebo neindexují. Údajně se tím nesnižuje „hodnota“ sitemapy.

V Search Console se také nyní reportují tzv. soft 404. Jedná se nejčastěji o zrušené stránky, které jsou přesměrované na jinou stránku, která není přímým ekvivalentem. Např. pokud několik zrušených stránek přesměrujete na homepage, nebo zrušené produktové stránky na kategorii. Roboti poznají, že přesměrování není adekvátní, jelikož obsah není totožný (podobný) a cíl stránky je jiný. Google poté vnímá tyto přesměrované stránky jako neexistující, tzn. nepředávají svoji hodnotu a hodnotu zpětných odkazů dál.

XML tagy poskytující informace o URL v Sitemap.xml

Možná víte, že do Sitemap.xml můžete přidat pomocí XML tagů doplňkové informace o jednotlivých URL. Např. tag <lastmod> určuje datum poslední změny na stránce, <changefreq> označuje frekvenci změn na stránce, pomocí <priority> tagu zase můžete prioritizovat URL webu dle důležitosti. John se vyjádřil, že jediný atribut, na který roboti hledí, je tag <lastmod>. Stává se, že webmasteři (ať už záměrně či ne) dávají do tohoto tagu nepravdivou informaci, např. nastaví u všech stránek totožné datum, které se vždy mění na dnešní či včerejší, aby bylo vidět, že se na stránkách stále pracuje a robot je tak navštěvoval častěji. Roboti však poznají, pokud informace zde nejsou pravdivé. Pokud se tomu tak stane, budou tag ignorovat a web procházet dle vlastního uvážení. Ostatní tagy roboti ignorují.

Poznámka: Pro mne je to docela zajímavá informace, jelikož se názory na to, zda Google bere ohled na tyto tagy, různí. Nyní víme, že roboti sledují tag <lastmod>.

Disavow file

Disavow file je stále možné využít pro distancování se od zpětných odkazů, které považujete za potenciálně „nebezpečné“. Je však procházen automaticky. Pokud do něj budete chtít přidat nějaký komentář, je to zbytečné – komentáře nikdo nečte. John se také vyjádřil, že tyto data nevyužívají pro další rozpoznávání např. spamových domén v rámci algoritmů.

Co způsobuje, že populární a kvalitní stránka se propadne z první pozice na 60+, během dalších týdnů se vrátí zpět na první místo a následně opět propadne?

John říká, že se to může stát. Nejedná se o žádný technický problém. Prý se jednoduše nemůže algoritmus kvality „rozhodnout“, zda je stránka dostatečně kvalitní, aby si první místo zasloužila konstantně.

Co z toho vyplývá? Neustále vylepšovat, testovat, vylepšovat…

Indexace JavaScriptových stránek

Několik poznatků:

• Základem je, aby každá stránka měla unikátní URL, a byla tak indexovatelná.
• Může být problém, pokud je k načtení stránky využíváno příliš mnoho JavaScriptů a externích zdrojů – to načítání podstatně zpomaluje. Ověřit je to možné v Search Console:
• Ověřit si, zda a jak robot vidí obsah těchto stránek, je možné přes funkci Fetch as Google v Search Console. Stačí si takto ověřit jednu stránku každé šablony webu. Pokud se načte a zobrazí jedna stránka šablony, je velmi pravděpodobné, že se stejně budou zobrazovat i ostatní (asi až na výjimky). Fetch as Google čeká na odpověď stránky cca 7-10 sekund. Roboti ve skutečnosti čekají o něco déle (nebylo specifikováno jak dlouho). Zásadní je, že pokud načtení stránky funguje v tomto nástroji, pak velmi pravděpodobně bude fungovat i ve skutečnosti vzhledem k robotům.
• John doporučuje Webpagetest.org, kde je možné podrobně analyzovat průběh načítání a konkrétní příčiny zpomalení.

Kdy se po přesměrování přenese hodnota přesměrované stránky na novou?

Většinou se hodnota přenese hned po první návštěvě Googlebota. Může se však stát, že to chvíli potrvá a hodnota se bude převádět po dobu několika návštěv. Tzn. ve finále je doba individuální dle toho, jak často robot stránku navštíví – to může být dny, ale také měsíce. John také upozornil, že je dobré ponechat nastavené přesměrování alespoň jeden rok. Poznámka: Hlavně kvůli zpětným odkazům, které na původní URL vedou.

Záležitost s canonicals

I URL, které jsou kanonizované pomocí značky canonical, Googleboti občas prochází. John potvrdil i fakt, že někdy se roboti mohou rozhodnout, že kanonizované URL, které jsou označené jako duplicita nebo jednoduše stránka, jejíž indexaci nepreferujeme, mohou zvolit jako primární URL pro indexaci. Jednoduše dle různých ukazatelů vyhodnotí, že námi méně preferovaná stránka je kvalitnější/relevantnější než námi preferovaná (kanonická) stránka.

Poznámka: Opět se nám tedy potvrzuje, že značky canonical nic negarantují a při větším počtu duplicit je potřeba stav monitorovat a případně zvolit jiné řešení. 

Spuštění několika jazykových mutací objemných stránek

Pokud máte web o velkém množství stránek (sta tisíce), nemusíte se bát spustit další jazykové mutace najednou. Někteří lidé mají pocit, že je potřeba u velkých webů stránky postupně vytvářet a „dávkovat“. Nestane se nic takového, jako „zahlcení indexu“ apod. Pokud se však jedná o tisíce, sta tisíce nových stránek, může trvat delší dobu, než je roboti všechny projdou a zaindexují. John samozřejmě doporučuje dodržet základní principy, jako párování mutací pomocí hreflang značek a unikátní (ručně přeložený) obsah.

Poznámka: Z toho odvozuji, že to neplatí pouze u jazykových mutací, ale obecně – není problém do indexu „pustit“ najednou sta tisíce stránek. 

Zde se můžete podívat na celou diskuzi s Johnem: