Stránkování produktu – duplicita – jak na ni?

Napsal petrx;1323097

Pokud je na produkt odkaz jen v kategorii na stránce č. 2 a ta je zablokovaná pro roboty, kde se bude nacházet hyperlink, který stránce produktu předá PageRank a Srank?

Úplně stejně jako by tam byl index, follow - příchozí se rozteče do odkazů, na které stránka odkazuje, pouze odkazovaná stránka nebude v indexu.---------- Příspěvek doplněn 08.09.2016 v 20:06 ----------To že stránka není v indexu neznamená, že ji roboti ignorují.

Pardon, četl jsem "noindex, nofollow" a nikoli "noindex, follow".V tom případě ale nechápu, v čem to "robotovi ušetří práci" -- 2. a další stránky výpisu stejně musí načíst a zpracovat, pouze je neuloží do databáze. Ale při výpočtu PageRanku / Sranku s nimi stejně počítat musí.Samozřejmě nechápu, v čem je opičárna s noindex lepší než paginace tak, jak ji doporučuje Google na stránceOfficial Google Webmaster Central Blog: Pagination with rel=“next” and…

Noindex, nofollow opravdu ušetří práci hlavně provozovateli :D Tak projít desitky, stovky, tisíce podstránek, které musí pochopit o čem jsou, porovnat jejich relevanci s ostatními nezabere zrovna málo strojového času a ve výsledku z toho nic moc nevytěží. Dlouhodobě se mi osvědčila technika "čím méně práce robotovi přidělám, tím mě bude mít raději". Což je příklad i třeba "escaped fragment", který také vyhledávače podporují a v nápovědách je schválený, nicméně neajaxová stránka je stejně rychleji zaindexována a zdá se mi (toto tvrzení nemůžu ničím s jistotou potvrdit), že se i lépe umisťuje. Neříkám, že je noindex lepší než rel="next/prev", nicméně se v něm dá udělat méně chyb při implementaci - je dost jednoduché udělat nekonečnou smyčku :-) Záleží samozřejmě na konkrétním webu, vyhledávač si sám určí, zda se next/prev bude řídit, noindexem se však řídit bude. To že by bych udělal řetězec tisíce stránek svázaných pomocí next/prev, které musí vyhledávač nejdřív všechny načít, pak spojit a pak stejně zjistí, že tam nic důležitého není, zrovna neodpovídá mému heslu nepřidělávání práce.

Napsal smitka;1323112

Noindex, nofollow opravdu ušetří práci hlavně provozovateli :D

Neříkám, že je noindex lepší než rel="next/prev", nicméně se v něm dá udělat méně chyb při implementaci - je dost jednoduché udělat nekonečnou smyčku :-)

No já jsem zase zažil spoustu chyb při práci s robots.txt a s "noindex, follow" / "noindex, nofollow".

Napsal smitka;1323112

To že by bych udělal řetězec tisíce stránek svázaných pomocí next/prev, které musí vyhledávač nejdřív všechny načít, pak spojit a pak stejně zjistí, že tam nic důležitého není, zrovna neodpovídá mému heslu nepřidělávání práce.

Při "noindex, follow" musí vyhledávač stránky také načíst, zpracovat a poslat PageRank kartám produktů, takže úspora práce pro robota moc velká není.Link graph musí uložit do databáze tak jako tak, akorát v případě "noindex, follow" neuloží texty 2. stránky výpisu produktů do databáze ("noindex"). Ale hyperlinky do databáze uložit musí ("follow"), aby se přenesl link juice.Pokud by se v rámci "noindex, follow" neukládaly ani informace o link graphu, ale jen o existenci odkazovaných stránek, link juice by se nepřenesl a stránky by dostaly nulový PageRank / Srank.---------- Post added 08.09.2016 at 22:02 ----------

Napsal smitka;1323112

Což je příklad i třeba "escaped fragment", který také vyhledávače podporují a v nápovědách je schválený, nicméně neajaxová stránka je stejně rychleji zaindexována a zdá se mi (toto tvrzení nemůžu ničím s jistotou potvrdit), že se i lépe umisťuje.

To zní rozumně, ale ve skutečnosti je to ještě horší:Google označuje kulišárnu s escaped_fragment za "deprecated"Full Specification | AJAX Crawling (Deprecated) | Google Developersa Google již kulišárnu s escaped_fragment oficiálně "nedoporučuje":Official Google Webmaster Central Blog: Deprecating our AJAX crawling schemeSeznam kulišárnu s escaped_fragment v zásadě umí zpracovat, ale píše:Indexace AJAX pomocí hashbang | Seznam Nápověda"Obecně tuto techniku pro weby s velkým počtem stránek nedoporučujeme, protože robot musí navštívit dvakrát více URL a stažení stránek tak může trvat déle."