Dušan Janovský o fulltextovém vyhledávání na Seznam.cz, část 2.

20. Květen 201520 komentářů

Mám znovu obrovskou radost, že si Dušan našel čas a energii odpověď na další otázky okolo fulltextového vyhledávání na Seznam.cz, které vzešly mimo jiné i z reakcí na první díl rozhovoru o vyhledávání. Snad se vám rozhovor bude líbit a odnesete si z něj kus moudra do praxe jako já :-)

 

Za spoustu problémů v SEO si webaři můžou sami tím, že znesnadňují robotovi práci. Které jsou ty hlavní časté chyby z pohledu Seznam.cz bota?

Jsou různé druhy webařů. Někteří vyhledávače vůbec neřeší. Ti často chybují v triviálních nastaveních, například v robots.txt zakážou indexaci celého webu nebo udělají celou stránku jedním obrázkem bez altu.

Pak existují webaři poučení, kteří nejčastěji chybují v tom, že něco překombinují. Hlavně chybují v přesměrování, v kanonizaci, ve vytváření duplicit, v používání javascriptu v menu.

Nešikovné jsou také weby, které na to, jak relativně málo mají obsahu, vytvářejí strašně moc různých URL, řádově třeba stovky tisíc. Úplně chytré není poskytování různého obsahu na jedné URL, třeba podle jazyka prohlížeče.

 

Chyby v kanonizaci, to mne zaujalo hodně :-) Dlouho se pořádně nevědělo, jak přesně s kanonizací Seznam.cz pracuje. Mohl bys ty chyby trochu rozvést?

 Popsat naši kanonizaci by bylo fakt na dlouho. Pokud jde o chyby, tak třeba vídáme kanonické linky opačným směrem. Místo toho, aby link odkazoval z nedůležité stránky na kanonickou verzi, tak je na stránce, která je evidentně kanonickou verzí, link na verzi s nějakými divnými parametry. Jako by tím autor chtěl říct “a tenhle brajgl kanonizujte taky sem”, ale je škoda, že k tomu používá zápis znamenající přesný opak.

 

Je třeba podle tebe správný postup řešit přes rel=”canonical” stránkování (u nás častá praxe)?

Je to myslím nejlepší řešení. Zejména ve výpisech, kde se často mění obsah těch dalších stránek. Na často se měnící stránkování nemá cenu uživatele posílat, protože tam stejně už pravděpodobně nenajde to, co tam bylo. Lepší je v tu chvíli skutečně kanonizovat a ranky soustředit na první stránku výpisu. Naopak u velmi stabilních výpisů, kterým se n-té stránky mění zřídka nebo nikdy, není třeba kanonizovat.

 

Jako alternativy ke kanonizaci se pro stránkování používájí značky rel=”next” a rel=”prev” případně meta robots “noindex, follow“. Někdy proto, že programátor nebo CMS canonical neumí nebo proto, že není 100% důvěra, že vyhledávače canonical budou chtít respektovat. Jak je to u Seznamu, jsou všechny tři postupy správné a použitelné?

 S rel next a prev při kanonizaci nepracujeme. Meta robots “noindex, follow” není nástroj úplně na kanonizaci, ale na neindexování stránky. Ano, může se to projevit tím, že je pak v indexu správná stránka, ale ten mechanismus je jiný než kanonizace.

 

Jak vůbec Seznam.cz pracuje s přesměrováními (třeba při redesignu webu), liší se nějak váš přístup od Google?

 Nevím, jak v tomhle ohledu funguje vevnitř Google. Myslím, že přesměrování implementuje jako nějaký druh kanonizace. My s kanonickými množinami v indexu nepracujeme, pro nás je hlavní entita v indexu URL. V minulosti jsme přesměrování měli implementované moc naivně, takže jsme při objevení přesměrování sice prioritně založili novou URL, na kterou přesměrování vedlo, ale zdroj přesměrování jsme odindexovali. To vedlo k nepříjemným propadům, kdy zdroj v indexu už nebyl a cíl přesměrování v něm ještě nebyl nebo se mu ještě nedopočítaly signály, odkazy apod. Nyní tam máme ochrannou lhůtu, kdy v indexu zdroj přesměrování necháváme a stěhujeme na něj dočasně obsah cíle. Opačným směrem stěhujeme dočasně signály zdroje, aby cílová URL nezačínala od nuly. Celé je to ještě poněkud složitější. Z přesměrování 302 například počítáme alternativní URL, což je přesměrovávaná adresa, kterou můžeme zobrazit ve výsledku namísto cíle přesměrování.

 

Osobně jsem se setkal s tím, že “narovnání” po přesměrování trvalo opravdu dlouho (měsíce). Asi byla ochranná lhůta kratší než čas potřebný na stěhování :-)

 To spíš bylo v době, kdy ten algoritmus fungoval dost jinak. Výrazně jsme ho měnili v průběhu loňského roku a dodělávali letos na jaře.

 

Jak můžu Seznamu pomoci proces urychlit, pokud už jsem v situaci že skutečně nějakou obchodně důležitou stránku nutně musím někam trvale přesměrovat?

 Určitě přesměrovávat přímo, bez nějakých mezipřesměrování. Ujistit se, že tam nejsou nějaké chyby (nové adresy musí být funkční, neblokované přes robots.txt, nezacyklené, nevracet captchu nebo pětikila) a ideálně to otestovat na části toho webu třeba týden předem. V případě opravdu velkých webů se statisíci nebo spíše milióny stránek popřemýšlet nad tím, jestli je nutno stěhovat úplně všechny adresy včetně nepodstatných, protože ty nové verze méně podstatných stránek pak můžou doméně v kritickém období zaplnit sosací frontu. Ze stejného důvodu je dobré pár týdnů před přechodem se zamyslet nad kanonizací méně důležitých stránek. U extra velkých webů pomůže také, když má hosting více IP adres a že odpovídá rychle.

 

Setkáváte se s nějakými chybami v použití přesměrování?

 Podívejme se na to opačně, kdy je přesměrování OK. Teoreticky existují pouze dva důvody, proč přesměrování akceptujeme. Prvním je stav, kdy na URL byl nějaký obsah, ale tento obsah se někam přesunul. Samozřejmě ho chceme najít i nadále, a tak takové přesměrování vítáme. Druhý důvod je tehdy, když někdo z různých důvodů odkazuje přes přesměrování. Odkazy máme také rádi, takže to je také OK.

 

Pak si ale představ situaci, kdy někdo hlavní stránku svého webu přesměrovává každý den na jiné URL. Evidentně se nejedná o situaci, že by přesunul obsah nebo chtěl odkazovat. Pokud taková přesměrování akceptujeme, tak se nelze divit, že hlavní stránka není k nalezení.

 

Jiný příklad špatného použití přesměrování většinou vzniká při stěhování webu, když majitel všechny staré URL přesměruje na hlavní stránku nového webu. Ničemu tím nepomůže, jenom zmate uživatele a my si takové redirecty při výpočtu některých ranků stejně interně zahodíme. Správné je samozřejmě přesměrování 1:1, pokud to jde. Tedy URL, kde byl starý obsah, přesměrovat na nové URL, kde je tentýž obsah nyní.

 

Pak jsou situace ne úplně jednoznačné – třeba když se nějaký produkt přestane prodávat, ale má přímého nástupce. Jaká je pro tebe preferovaná varianta z pohledu vyhledávače – držet na webu produktovou kartu s informací “vyprodáno, nástupce si prohlédni kliknutím zde”, vrátit 404 nebo přesměrování na nástupce?

 Nevím. Sám říkáš, že to není jednoznačné. Asi bych volil různé situace podle toho, jak evidentní nástupce to je. 404 nebo 410 je docela dobré řešení, protože tím z webu zmizí různí kostlivečci. Když je takových “junkových” stránek na webu moc, tak to robotovi moc nechutná. Na druhou stranu informace o evidentním nástupci může být pro uživatele užitečná. Přesměrování bych volil jen v individuálních případech. Zejména takových, kdy se třeba musí změnit adresa URL kvůli přejmenování jednoho a téhož výrobku.

 

Hodně palčivým tématem je indexace. Co jsou typické bariéry, kvůli kterým mně nebude chtít Seznam indexovat web?

 Copak o to, my bychom chtěli indexovat leccos. Ale s konečným počtem serverů jednou musí jednou přijít n-tá miliarda stránek, kterou už do indexu nenarveme. A tehdy se musíme rozhodnout, co do indexu dát a co ne. Spíše než bariéry jsou to nějaké fuzzy veličiny, s nimiž se zvyšuje nebo snižuje pravděpodobnost zařazení do indexu.

 

Pak existují situace, kdy indexovat chceme, ale nedokážeme. Typicky velké servery, které na to, kolik mají obsahu, nestíhají odpovídat. Případně nás také blokují.

 

Jmenoval jsi použití Javascriptu v menu jako zdroj chyb. Můžeš pro méně zkušené čtenáře upřesnit v čem, ukázat nám nějaký příklad špatné implementace?

 Pokud někdo udělá podstránku, na kterou nevede žádný odkaz a uživatelé se tam z jiných stránek dostávají jenom přes javascriptové menu, tak je nutno počítat s tím, že náš robot takovou stránku nemusí objevit, protože javascript v robotovi kompletně neinterpretujeme.

 

Řeší nějak Seznam obsah, který je Javascriptem nebo jinak skrytý a dostupný až “na požádání”? Třeba detailní popisky produktů v “záložkách” nebo text skrytý za “číst více”. Google oznámil, že takový obsah (který není vidět hned) nemusí chtít indexovat nebo mu může “přikládat nižší důležitost”. Dělá to Seznam podobně?

 To jsou dvě otázky najednou. Záleží na technologii, kterou je to skrývané. Pokud text na stránce není a do stránky je dopisován javascriptem, nebo je javascriptem dopisovaný odkaz na takový text (viz odpověď výše), tak ho nezaindexujeme. Pokud je text skrytý jenom přes CSS a javascriptem je odkrývaný, tak v tuto chvíli tento text chápeme jako součást stránky a na stránce jej najdeme. Ale v trénovacích datech našich algoritmů taková stránka bude na dotaz, jehož odpověď je skrytá stylem, pravděpodobně označena jako nerelevantní. CSS částečně interpretujeme, takže je možné, že naše algoritmy se to naučily nebo naučí samy.

Jiná situace nastává, pokud je na stránce skrytý text pouze za účelem zmatení vyhledávání. V takových situacích stránku samozřejmě ručně penalizujeme.

 

Zmínil jsi duplicity jako častý problém. Myslím, že potíž pro hodně webařů je vůbec definice duplicity – co je ještě “hodně podobný, ale ok obsah” a co ne (třeba když řeší, že přebírají desítky tisíc produktů na eshop od dodavatele, nemají zdroje na to všechny přepsat na unikátní a bojí se problémů s vyhledávačem). Můžeš trochu upřesnit, jak to vnímá Seznam.cz?

 Nelze odpovědět jednoduše, protože duplicity řešíme na více místech a pokaždé trochu odlišným způsobem. Něco v robotovi, jiné věci si počítáme při indexaci a pak to používáme při agregaci výsledků. V zásadě odlišujeme dva typy duplicit: úplné a částečné. Úplné duplicity jsou na bajt stejné obsahy. Ty většinou vyřazujeme už na straně robota a pro dotyčný web je to vlastně dobře. Většinou to jsou stránky, které se liší jenom parametrem v adrese, který ale nic nedělá. Dost úplných duplicit leze i z běžných redakčních systémů. Částečné duplicity řešíme přes simhash nebo minhash z různých n-gramů. Někdy je vstupem jen důležitý obsah stránky, jindy kompletní obsah včetně menu (boilerplate). Nechci zacházet do detailů, tak popíšu jenom použití hashů. Robot si z částečných podobností staví pomocí simhashí jakýsi orientovaný graf, který mu pomáhá při rozhodování, co crawlovat a co ne. Tolik robot. Při indexaci se pak počítají jiné hashe, konkrétně 32 2-bitových minhashí, které se ukládají do indexu.

 

Po zahledání při agregaci SERPů potom u každého výsledku sledujeme, jestli nad ním už v SERPu není jiný relevantnější dokument, který má mnoho společných textových minhashí, řekněme 24 z 32. Pokud ano, do SERPu ho nezařadíme, protože je vysoce pravděpodobné, že se z více jak ze 3/4 shoduje s něčím, co už ve výsledku je. Weby, které mají své texty hodně podobné jiným, se tedy často do výsledku nedostanou. Toho si po čase všimne robot a řekne si, že když se z nějakého webu moc často filtrují semiduplicity, tak že asi nemá smysl to ani moc crawlovat. Nedá se tomu říct penalizace, spíš neochota k dalšímu indexování. (Mimochodem z tohoto důvodu je lepší, když robot předem může zahodit úplné duplicity.)

 

Já velké shopy chápu, že se jim nechce psát vlastní texty k mnoha výrobkům. Na druhou stranu určitě zase chápeš Seznam, že v indexu fakt nepotřebuje kopii stejného textu s pořadovým číslem dvacet tisíc jedna. Jestliže někdo nemá kapacity na sepisování unikátních informací o výrobcích, může z našeho pohledu konkurovat jenom cenou a dodacími podmínkami. To jsou důležité údaje, ale na jejich agregaci doporučujeme zařazení do naší specializované služby Zboží.cz.

 

 

Je pro rychlost a rozsah indexace důležitým faktorem i rychlost načítání webu – ve smyslu že pomalé weby jsou třeba nějak znevýhodněné?

 Rychlost stránek sledujeme na úrovni robota při stahování. Zajímá nás, jak rychle dostaneme odpověď v HTML, protože stahujeme jenom HTML zdroj bez externích CSS, a javascriptů a dalších objektů. Rychleji odpovídající stránky potom robot raději reindexuje a u rychle odpovídajících webů raději zakládá nové URL. Důležité je to hlavně u velmi velkých webů s desítkami tisíc až milióny stránek. Do relevance zatím rychlost stránek přímo nepromítáme. Až ji budeme promítat, spíše než o rychlost stažení samotného HTML půjde pravděpodobně o rychlost vykreslení.

 

Když jsme u pochopení webu – s jakými všemi meta daty a značkami umí dnes Seznam.cz pracovat?

 Meta data je široký pojem. Pro mě to jsou hlavně informace, které jsou o stránce, ale nejsou na stránce. Jsou někde za ní. Takže za meta data lze obecně pokládat třeba i odkazy nebo informace o webserveru. Ty se ale asi ptáš na meta značky v HTML nebo na mikroformáty. Z meta tagů samozřejmě koukáme na robots, refresh nebo description. Naopak téměř vůbec nekoukáme na meta tag keywords. S meta tagy v dokumentu, které by měly nést význam, je ten problém, že jejich obsah uživatel nevidí. Autoři na ně proto zapomínají nebo jimi v horším případě klamou. A pro nás je mnohem důležitější to, co uživatel na stránce může vidět a číst, než to, co nevidí, tedy meta tagy. V textu stránek je o několik řádů více informace než v meta značkách a mikroformátech.

 

Z mikroformátů si aktuálně všímáme jenom mikroformátu Geo, který umožňuje umístit GPS souřadnice do atributu místo jejich vypisování na stránku. Bude se nám to hodit, až budeme lokalizovat hledání. Teď to používáme jen na to, že u snippetu zobrazíme odkaz na mapu, což ale pro autory stránek není žádná motivace, protože ten malý odkaz vede na naše mapy a ne na jejich stránky. Lokalitu, o které stránka pojednává, je v praxi potřeba zjistit jinými metodami, což naštěstí jde. Například rozpoznat, že literál je GPS souřadnice, je snadné. Nemusíme nutit autory stránek obalovat to ještě nějakými zobáčky.

 

Vždycky mně trápilo, že meta description si Seznam.cz pro snippet někdy vezme a někdy ne. Podle čeho se rozhodujete, co si do snippetu vzít?

 Mě to taky trápí. Teď jsme se rozhodli snippetování opět přepsat, takže to zase bude jinak. Nemá tedy smysl popisovat současný stav, který zanikne. Obecně se vždy budeme snažit, abychom snippet brali z meta description tehdy, když se bude jevit jako relevantnější než úryvek ze stránky. (Snippet ve výsledcích vyhledávání je ten úryvek ze stránky pod každým odkazem.)

 

Plánujete podporu třeba pro schema.org (např. pro zobrazení ceny nebo hodnocení produktu v SERPu)?

 Pokud budeme podporovat další mikroformáty, pojedeme podle schema.org a nebudeme vyhlašovat vlastní značky. Pokud. Například u hodnocení produktu zobrazeném v SERPu cítím nejistotu uživatele, zda se hodnocení týká produktu, které poskytuje stránka, nebo spíše hodnocení stránky, které poskytuje vyhledávač. Podle mě to uživatelé chápou spíš jako hodnocení stránky. Označení ceny je hezké, ale nestíhali bychom ho aktualizovat. Myslím, že pokud budeme do SERPu takové věci připojovat, spíše použijeme aktualizovaná data z našeho Zboží.cz, než abychom věřili mikroformátům. Ale to spekuluji.

 

V SEO kruzích se hodně řeší a nadává na citlivost Seznamu na klíčové slovo v URL. Vnímáš to jako reálný problém pro výsledky vyhledávání?

 Je to velký problém. S přestávkami se jím zabývám už asi tři čtvrtě roku a fakt, že jsme se neposunuli, chápu jako svoje osobní selhání. Udělali jsme k tomu několik výzkumů a žádný velký průlom.

 

Za prvé nedokážeme problém dobře definovat a kvantifikovat. To, že jsou ve výsledcích stránky s hledanými slovy v doméně, totiž není vždy špatně. Určitě je to dobře v případě navigačních dotazů a překvapivě často jsou hledaná slova v doméně v pořádku i u komerčních dotazů. Takže nemůžu sestavit zadání typu “vyhoďme z výsledku všechny výsledky s hledaným slovem v doméně”, protože to tak prostě není. Všechny další nápady, jak definovat problém se slovy v doménách, vypadají zatím dost obskurně, což mě odrazuje na nich stavět.

 

Za druhé naše modely se na nasbíraných datech, o kterých jsme mluvili v minulém rozhovoru, naučily, že to současné chování je v pořádku. Jasně že se ve spočítaných rozhodovacích stromech najdou větve, které říkají, že co je moc, to je moc. Naprostá většina větvení ale říká, že co má hledané slovo v doméně, to je lepší než to, co ji tam nemá. Pokud použijeme naše současné přístupy strojového učení, tak k jinému výsledku potřebujeme jiná data, což ale není v dohledu. Naši brigádníci při přípravě dat správně vidí, že na většině stránek s klíčovými slovy v doméně je relevantní obsah. Nemají žádný důvod snižovat hodnocení, jenom protože nějaké slovo je v doméně.

 

Jeden z možných přístupů by mohl být, že se rozhodovacím lesům informace o hledaných slovech v doméně vůbec nepředá. A protože ji nebudou mít, nebudou podle ní moci rozhodovat. Naneštěstí se ukazuje, že v takovém případě výrazně klesá kvalita výsledků, hlavně u navigačních dotazů. Měli jsme v minulosti i řešení, že se navigační dotazy počítaly jiným modelem než zbytek dotazů, ale ani to tento problém neodstranilo, tak jsme se vrátili k modelům pracujícím se všemi dotazy.

 

Částečně úspěšnou cestou je přidávání nových signálů spočítaných z jiných dat než z URL, které evidentně nesou podobnou informaci jako signály počítané z domén, protože doménové signály z lesů trochu vytlačují. Ale jenom trochu. Skutečný průlom očekávám až poté, co se objeví nějaké nové přístupy k učení boostovaných rozhodovacích stromů. Něco jako je deep learning u neuronek, ale se stromy. Cítím, že bychom potřebovali některé signály předučit na to, kdy je doména vzhledem k dotazu smysluplná a kdy není. Bude to ale muset být na jiných datech než na těch, která dnes máme.

 

Samé výmluvy, co? Každopádně na tom chci dál pracovat.

 

 Dušane, nedávno jste vypustili update Jalapeňo s cílem zabojovat s nehezkými SEO technikami a spam weby. Já si toho obrovsky cením a mám radost! Dokážeš už teď po krátké době říct, zda update pro vás plní svůj cíl podle očekávání?

 My jsme si přibližný efekt změřili předem, takže nejistota byla jenom v tom, kolik se po spuštění ještě objeví nesprávně klasifikovaných případů. Občas někdo něco nahlásí, ale těch případů je relativně málo, takže zatím to jde podle očekávání.

 

Je to jednorázová akce, nebo lze očekávat ještě letos další akce tímto směrem?

Japaleňo je významná aktualizace ve dvou ohledech. Jednak používáme k práci se spamem některé nové přístupy, takže tomu nyní dost věříme. Za druhé tuto aktualizaci veřejně komunikujeme, což jsme dříve u podobných aktualizací nedělali. Nechtěli jsme být ten pes, který štěká, ale nekouše. Proto aktualizaci komunikujeme až teď, kdy jsme si jistější. První projekt na odfiltrování spamových stránek jsme v Seznamu měli už v roce 2007 a od té doby jsme na tom nikdy nepřestali pracovat. Svou podstatou tedy Japaleňo není úplná novinka a určitě to není ani krok poslední, protože je v našem bytostném zájmu, abychom ve výsledcích neměli špatné stránky. Jestli budeme letos něco dalšího oznamovat, to nyní ale nedokážu říct.

 

 

Další užitečné zdroje informací:

 

Chcete se k nějakému tématu Dušana dozeptat? Zajímá vás nějaké docela jiné téma, které zatím v rozhovorech nezaznělo? Nesouhlasíte? Těším se na názory dole v diskuzi :-)

 20.5.2015 napsal Lukáš Pítra

Komentáře 20 Přidat komentář

  1. Pavel Ungr napsal:

    Pánové, díky za skvělý rozhovor plný cenných informací.

  2. Tomáš Paulík napsal:

    Díky moc za rozhovor. Pro nás, kteří nemáme velká data a možnost detailně testovat chování vyhledávačů je to velmi zajímavé nahlédnout pod pokličku vyhledávání Seznamu.

  3. O. Brandos napsal:

    Za mne rovněž velký dík za zajímavý rozhovor a množství užitečných informací.

  4. Milan napsal:

    Dotaz, nebo spíše přání…. nedočkáme se od seznamu nějakého „webmaster tools“?

  5. Marek Prokop napsal:

    To přísné filtrování meziwebových duplicit resp. podobností mě dost překvapuje. Kdyby to vyhledavač opravdu dělal (což naštěstí Seznam tak úplně nedělá), selhával by v docela častých use casech. Ostatně představa, že obchody s neunikátními popisky zboží mohou konkurovat jenom cenou a dodacími podmínkami, je tak naivní, že ji Dušan přeci nemůže myslet vážně.

    Dost mě překvapuje i doporučení kanonizovat stránkování pomocí link rel cononical. Když tuhle radu někdo mechanicky provede, nebudu mít pak možná v indexu většinu stránek, které z těch stránkovaných seznamů odkazuje.

  6. Pavel Drábek napsal:

    Super článek. Díky a doufám, že informace tohoto druhu bude seznam prezentovat častěji. BTW pod článkem je rok 2014

  7. Tomáš Kouba napsal:

    Supr článek, díky za něj! :)

    Ale jak píše Marek, rel=canonical na stránkování mě taky hodně překvapuje. Google tento přístup vyloženě nedoporučuje, takže bych se mu raději vyhnul a místo toho jen použil rel=prev/next, které Google naopak doporučuje. A kdyby byl problém s indexací, zkusil bych leda noindex, follow.

    Taky mě překvapilo, jak Yuhů říkal, že u komerčních dotazů hrají odkazy minimální roli…

    Jestli budeš, Lukáši, dělat ještě jeden rozhovor, zkus se prosím zeptat, jaké jsou ty otázky, na které kalibrátoři odpovídají. To by bylo hodně zajímavý! :)

  8. Milky napsal:

    Marku, v žádném případě nechci oponovat autoritě Vašeho kalibru, ale jen se chci zmínit jak rel canonical chápu já. Pokud jej použiji např. u stránkování, měl by ještě existovat z kanonické adresy (stránka s url bez parametru stránkování) odkaz na všechny záznamy v dané kategorii. V případě, že robot navštíví odkazovanou stránku má k dispozici kompletní seznam záznamů, které v dané kategorii existují.
    Snad to chápu správně.
    Jinak chlapi, děkuji, přínosný rozhovor/článek.

  9. Marek Prokop napsal:

    Milky, ano, to by pak bylo OK.Proto píšu, že není vhodná *mechanická* aplikace té rady, tj. na běžný web bez dalších úprav.

  10. David Teska napsal:

    Líbí se mi ten Dušanův otevřený přístup k sérii rozhovorů. Opět díky za hodnotné informace.

  11. Ondrej Brablc napsal:

    Článek je super, zkusím sem propašovat technickou otázku ;-)

    Dnes se mi postaral o zábavu „secret-agent/007“ z IP adresy cache.seznam.cz. Za odpoledne udělal přes milion hitů na celkem 750 eshopů za jednou IP adresou. Poprvé, co se povedlo nějakému robotu poslat Apache do kolen, kvůli zápisům do logů. Do toho k webům přistupoval screenshotovač.

    Jaká je doporučená obrana proti něčemu podobnému? Je použití UA „secret-agent/007“ a podobná kadence dotazů etická?

  12. Yuhů napsal:

    Marek Prokop: Při filtrování meziwebových podobností opravdu selháváme v některých use casech. Zejména v situacích, kdy uživatel chce najít stejný text na různých webech. Typicky se jedná o texty písniček nebo úryvek z přesného popisku zboží, u kterého chce uživatel porovnat cenu. Myslíš těmi častými use casy tohle? Máme vymyšlené nějaké přístupy, kterými bychom do budoucna mohli to filtrování vylepšit. Navíc ono to funguje ještě trochu složitěji, než jsem to popsal, takže ta situace není tak hrozná. Přeci jen toto měl být populární článek, tak jsem se snažil být stručnější.

    Obchody s neunikátními popisky mohou konkurovat pouze cenou a dodacími podmínkami. Z mého omezeného pohledu to platí. Je pravděpodobné, že jsem v tom naivní, ale pamatuj, že se musím pohybovat v rámci vlastností, které dokážeme implementovat. Ty máš, Marku, s byznysem shopů mnohem více zkušeností než já, takže vidíš širší souvislosti. Rád si nechám poradit.

    Pokud jde o stránkování přes rel cannonical: abychom na stránce objevili kanonický link, tak ji musíme stáhnout. A když už je stažená, tak z ní bereme odkazy. A pokud se jeví ta nekanonická URL jako důležitá (vedou na ni odkazy), tak ji stejně pravidelně navštěvujeme a sledujeme, jestli na ní stále ten kanonický link je. A přitom zase vidíme odkazy, které tam jsou. Připouštím, že to celé stránkování je poněkud problematické. Ačkoli jsem použití kanonického linku v odpovědi označil za nejlepší, nikde netvrdím, že to je řešení dobré. V případě často se měnících stránkování s více parametry je to podle mě nejlepší špatné řešení.

  13. Milan napsal:

    přetěžování webu robotem mě taky dost potrápilo, bere seznam bot opravdu důsledně pravidla v robots.txt, co se týče doby kdy může web navštěvovat a kolik stránek za minutu může stáhnout?

  14. Tomáš Paulík napsal:

    Když tu máme Dušana v diskuzi, tak bych se rád zeptal, jak je na tom Seznam s indexací webů běžících na HTTPs. Předem děkuji za odpověď.

  15. Marek Prokop napsal:

    Děkuju za odpověď, Dušane. K těm meziwebovým podobnostem zkusím časem něco napsat jinde, sem by se to nevešlo. Pokud jde o link rel canonical, potíž je v tom, že Google a další vyhledavače se mohou chovat jinak a ostatně Seznam se taky někdy může začít chovat jinak — je to prostě z pohledu webmastera nedostatečně standardizovaný a zdokumentovaný black box.

  16. Milan napsal:

    Dotaz na priste: jak resit adresy filtrů v eshopech? Jedná se o duplicitu? Vyfiltruji v kategotii produkty podle velikosti, zmeni se h1, title , ale zustane stejný popis…

  17. Janek napsal:

    „Naopak se téměř vůbec nedíváme na meta-keywords“…takže to, že mk jsou úplně k ničemu je (byla) jen SEO fáma. Nějaký vliv to tedy má. Díky za článek.

  18. Martin Tejkl napsal:

    Já bych se chtěl zeptat na přechod stránek na HTTPS, všichni víme, že seznam s tímto přechodem ma problémy, ale co se dostalo ven z fulltext týmu, tak že se na tom má pracovat, jak to tedy je? Pracuje se na nějaké úpravě na rychlejší přesun na Sko a je nějaký časový odhad kdy by případně mohlo být. V dnešní době se o Sku hodně mluví, ale přesunu se dost lidí bojí, kvlli propadu na seznamu.

  19. Ta formulace ohledně meta keywords mě taky zaujala. :) To jsem zvědavý, jestli se k tomu Dušan ještě vyjádří. Zase by spousta lidí měla o čem psát a točit videa.
    Jinak Dušanovi děkuji za otevřenost a Lukášovi za rozhovor jako takový. Jen víc takových.

  20. Yuhů napsal:

    Ta keywords se používají pouze jako nápověda pro odlepovač slov. Když jsou v URL slepená slova a snažíme se je odlepit a zaindexovat, tak se v případě nejistoty algoritmus dívá do textu stránky. Plus meta keywords, což se nám vyplatilo zejména na prázdných stránkách, různých vstupních chodbách, flashových prezentacích a podobně. Jinde meta keywords nepoužíváme.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Další podobné články