User-agent: *
Disallow: /

Zapamatujte si jednoduché pravidlo. Robots.txt neslouží k zákazu indexace stránek. Nikdy a ani trochu. A naopak může uškodit.

Indexace versus crawlování

Pro pochopení je nutné znát rozdíl mezi crawlováním a indexací. Crawlování znamená, že se robot vyhledávače prochází po vašem webu a stahuje si k sobě od vás jednotlivé stránky pro další zpracování.

Indexace je pak sestavování indexu – tedy databáze, ve které fulltext po zadání dotazu hledá. Do indexu přitom zařazuje stránky a informace o nich získané nejen z crawlování, ale i z dalších zdrojů, které vyhledávači přijdou zajímavé a užitečné.

Typicky už jenom tím, že se na nějakou konkrétní stránku odkazuje odjinud, dostává vyhledávač o dané stránce řadu zásadních informací – link text odkazu, klíčová slova v její URL, tematický kontext, ze kterého se na ni odkazuje, podobu a sílu jejího odkazového profilu. Další údaje může získat z popisků či kategorií v katalozích, do kterých je stránka zařazena. A tak dále.

Co je na zákazu indexace přes robots.txt špatně?

Robots.txt nezakazuje zařazení dané stránky do indexu, ale jen a pouze její crawlování robotem vyhledávače. Říkáte tím tedy, že si na danou URL nesmí crawler přímo sáhnout a stáhnout si k sobě její obsah.

Vyhledávače si ale i nadále můžou zařadit stránku do indexu jen na základě dalších údajů z jiných zdrojů a nabízet ji ve výsledcích hledání. A skutečně to velice často dělají:

Je vidět, že informace, které Google o stránce na SERPu zobrazuje, nepochází ze samotné stránky, ale právě z nějakého link textu a dalších zdrojů v okolí dané stránky. Všimněte si, že vyhledávač uživatele upozorní, že o stránce má jenom dílčí neúplně informace. Ale i přesto ji indexuje, nabízí a zobrazuje.

Jak tedy správně zakázat indexaci?

Správný zákaz indexace závisí na kontextu a důvodech, proč to vlastně vůbec chcete dělat:

Link rel=canonical

V případě, kdy máte na webu duplicity nebo silné podobnosti, které nelze vyřešit sloučením všech stránek v jedinou a přesměrováním ostatních přes HTTP 301, je místo zákazu všech duplicitních variant lepší použít meta značku canonical:

<link rel="canonical" href="http://www.example.com/my-canonical-page"/>

Nejedná se o zákaz indexace v pravém slova smyslu, ale spíš o nezávaznou nápovědu vyhledávači, kam by měl všechny duplicitní a podobné stránky kanonizovat. Výhodou je, že pokud na to vyhledávač přistoupí, koncentruje do navržené kanonické stránky odkazy a rank ze všech takto označených stránek. Nevýhodou je, že to vyhledávač nemusí vůbec respektovat.

Meta robots noindex

Tohle je ta správná, čistá a bezpečná metoda, jak skutečně zakázat indexaci dané stránky. Do její HTML hlavičky přidáte meta značku:

<meta name="robots" content="noindex"/>

Využijete to v případě stránek, na které vůbec nechcete, aby vám uživatelé chodili z vyhledávačů napřímo. Typicky třeba kroky nákupního procesu nebo děkovací stránky po odeslání konverze. Čistě pro jistotu i všechny stránky s nějakými neveřejnými citlivými údaji, i přesto, že ty máte určitě všechny dávno schované za přihlášením.

Po meta robots noindex sáhnete i v případě, kdy se reálně potýkáte s duplicitami či podobnostmi, ale vyhledávač odmítá zohlednit navržený meta canonical. Nevýhodou je, že se vám pak rank tematicky nekoncentruje v ideální kanonické stránce, ale rozplizne se vám bezkontextově přes všechny odchozí odkazy do zbytku webu.

HTTP hlavička X-Robots-Tag

Alternativa k meta robots noindex. Jenom místo HTML zdrojáku se posílá přímo v HTTP hlavičkách v HTTP odpovědi od serveru:

HTTP/1.1 200 OK
Date: Tue, 25 May 2010 21:42:43 GMT
(…)
X-Robots-Tag: noindex
(…)

Čili v zásadě totéž jako meta robots noindex. Jenom je to složitější na implementaci – HTML tag vrazí do zdrojáku každý, HTTP hlavičky už jsou vyšší dívčí. A navíc písmeno X na začátku naznačuje, že je to nestandardní HTTP hlavička, takže nemusí být podporovaná zdaleka všemi vyhledávači. Takže meta robots noindex bude asi většinou lepší variantou.

Více viz článek Robots meta tag and X-Robots-Tag HTTP header specifications.

HTTP autentizace

Zejména pro testovací verze vyvíjeného webu se místo zákazu indexace hodí skrýt paušálně celý web za HTTP autentizaci. To se zapíná obvykle přímo v konfiguraci daného webového serveru. Testovací verze webu se schová za heslo, takže na ni nevidí nikdo nepovolaný. Vedlejším efektem pak je, že je chráněna i před nechtěným zcrawlováním a indexací vyhledávačem.

Čistě formálně vzato, stejně jako u robots.txt platí, že ani HTTP autentizace přímo nezakazuje indexaci, jenom se crawler nedostane k samotným stránkám. U testovací verze webu se ale neočekává, že by měla nějaký smysluplný odkazový profil a vnější kontext, ze kterého by mohl vyhledávač čerpat další informace. A i kdyby ji nějakým omylem zaindexoval, tak příchozí návštěvníci z vyhledávače narazí nanejvýš tak na přihlašovací formulář. Takže pro náš účel poslouží HTTP autentizace zpravidla uspokojivě.

Výhodou je i to, že po překlopení webu na ostrou doménu se často meta robots nebo robots.txt zákazy zapomínají odstranit, takže vedou obratem k vypadnutí celého webu z indexu vyhledávačů. U HTTP autentizace je riziko nechtěného zapomenutí minimální.

Pozor na chybné kombinace

Teď už víte, že pro zákaz indexace slouží primárně meta robots noindex. Možná vás napadne, že pro jistotu to stejně navíc podpoříte současným zákazem v robots.txt. Čistě pro sichr, co kdyby, za to nic nedáte.

To je ale přeci úplně špatně! Jen si to srovnejte v hlavě. Tím, že robotovi zakážete přistupovat na vaše stránky, nemůže si stáhnout HTML zdroják, takže se ani vůbec nedozví o tom, že tam nějaký meta robots noindex je. V důsledku paradoxně může tyto stránky vesele indexovat a nabízet ve výsledcích hledání.

Robots.txt prostě opravdu nesmí být u zákazu stránek ani trochu.

Obdobně doprovodí řada lidí meta robots noindex ještě dalším parametrem nofollow. Přeci čím víc zákazů, tím jistější:

<meta name="robots" content="noindex,nofollow"/>

Ve skutečnosti tím ale zakážete následování interních odkazů ze stránky dál a dost možná i přelévání ranku do zbytku webu. Vytvoříte tak černou díru na rank, což se vám může promítnout do nižších pozic obecně celého webu. Ale vy chcete zachovat a předat co nejvíce ranku, chcete, aby robot snáze objevil indexovatelný zbytek vašeho webu. Správný zápis je tedy:

<meta name="robots" content="noindex,follow"/>

S tím, že follow je výchozí hodnota, takže ji můžete úplně vynechat. Nofollow smysluplně použijete opravdu tak jednou za sto let.

A k čemu tedy v praxi využiju robots.txt?

Zůstává otázka, k čemu tedy vlastně robots.txt je, když ne k zákazu indexace.

Je přesně k tomu, k čemu byl navržený. Tedy pro zákaz přímého přístupu robota na web nebo nějakou jeho dílčí stránku. To se občas hodí, sic zdaleka ne tak často, jak jste si mysleli.

Například pokud máte URL, jehož pingnutím se hlasuje v nějaké anketě, a nechcete, aby vám roboti při procházení vaším webem přičítali hlasy. Totéž platí pro jakékoliv trackovací a přesměrovací skripty, například pro počítání návštěvnosti nebo prokliků z reklamního systému:

User-agent: *
Disallow: /poll/vote
Disallow: /clickthru

Roboty budete chtít někdy zakázat také z výkonnostních důvodů. Ať už na dílčích skriptech a stránkách, jejichž každé zobrazení představuje složitý výpočet náročný na serverové zdroje či vám prostě přijde zbytečné, aby si je vyhledávač stahoval:

User-agent: *
Disallow: /overkill-page

Anebo třeba přes robots.txt můžete paušálně odříznout nějakého konkrétního robota, pokud je neukázněný a sestřeluje vám web:

User-agent: badbot
Disallow: /

User-agent: *
Disallow:

Pořád jenom roboti. A co lidi?

Aby to bylo spravedlivé, máme tu pro zájemce jako bonus na závěr i standard humans.txt.

Podívejte se například, jak si žijí humans.txt na našem Medio webu!

Související odkazy

• Daniel Bradbury Dočekal: Robots.txt? K čemu něco takového je? A proč je to užitečné?
• Lindsay Wassell: Serious Robots.txt Misuse & High Impact Solutions

Několik dobrých návyků na úvod

Jedině s preprocesorem

Používání Bootstrapu bez preprocesoru nelze nazvat jinak než slepou uličkou. Používat zbytečně celý vygenerovaný Bootstrap, když z něj využijeme jen několik málo procent, je špatný nápad. Tím spíše dnes, kdy se díky (nikoli kvůli) mobilnímu internetu musí znovu hledět na výslednou velikost stránek. Naklikat si potřebné komponenty a vygenerovat si CSS přímo ze stránek Bootstrapu je už lepší řešení, ale stále dost nešikovné. Nainstalovat si vše potřebné, co k používání preprocesoru potřebujeme, je otázka několika minut a benefity, které používáním preprocesoru získáme, jsou velké. A i když existují porty Bootstrapu do SASSu i Stylusu, je zdaleka nejlepší a určitě nejjednodušší používat nativní LESS.

Nešťourat se v Bootstrapu

Nedělat v LESS modulech Bootstrapu žádné změny je jednoznačně dobrý nápad, který oceníte při aktualizaci na novější verzi frameworku. Čestnou výjimku tvoří soubory bootstrap.less, kde se importují potřebné moduly, lépe řečeno zakomentují ty nepotřebné, a variables.less, ve kterém si můžeme Bootstrap „obléct“ do svých barev a fontů, nastavit paddingy a mnoho dalšího.

Zvažte, kdy je vhodné Bootstrap použít

I když v poslední době používám Bootstrap téměř na vše, jednu čestnou výjimku jsem za poslední rok měl. Byl to atypický web, kde by bylo použití Bootstrapu spíše kontraproduktivní, proto jsem z něj použil pouze mixiny. Určitě je tedy dobré předem myslet také na to, zda je opravdu potřeba Bootstrap použít.

Když už ho použijete, využijte ho

Na naprostou většinu prvků, které „vypadnou“ od grafika, můžete použít nějakou Bootstrap komponentu. A to platí i v případě, že grafik s použitím Bootstrapu předem nepočítal. Když už Bootstrap používáme, je z mnoha důvodů (budoucí úpravy, práce více lidí v týmu…) dobré maximálně využít jeho komponenty. Takže předtím, než začnete psát vlastní HTML, je dobré zamyslet se, zda je to opravdu potřeba.

Neškrábat se pravou rukou za levým uchem

Někdy je ale vlastní HTML nejlepší řešení. Je v grafickém návrhu prvek, u kterého váháte, jakou Bootstrap komponentu pro něj použít? Možná bude nejlepší nepoužít žádnou a napsat si HTML i CSS kompletně sám. Čím déle Bootstrap používám, tím více se snažím využívat maximálně využívat jeho komponenty, ale vlastní HTML je někdy to nejjednodušší a nejlepší řešení.

Jak Bootstrap používáme u nás

Prohlédněte si část našeho interního frameworku, ve kterém vyvíjím nové šablony.

1) Ve složce /bootstrap jsou všechny LESS moduly Bootstrapu. A jak jsem psal výše, v této složce se vůbec nešťourám (zde dokonce bez výjimky).
2) Ve složce /modules mám připravené vlastní LESS moduly – jsou tam ty „základní“, které používám na každém projektu. Projekt od projektu se pak rozhoduji, zda se pro přehlednost vyplatí přidat nějaké další.
3) Poslání souboru ie8.less je myslím jasné už z jeho názvu a netřeba vysvětlovat. Jsem rád, že tento soubor zůstává poslední dobou téměř nebo úplně prázdný :-)
4) Soubor main.less si zaslouží vlastní nadpis.

main.less

V tomto souboru se importují jednotlivé moduly, kompiluje se z něj také výsledné CSS. Nejdříve se naimportují potřebné Bootstrap moduly. Jak si můžete všimnout, „v základu“ mám pouze ty nezbytné (scaffolding, grid…) a ty „nezbytné“ (forms, buttons), zbytek je zakomentovaný. Následně importuji svoje moduly, na závěr pak ty responzivní. Responzivní moduly jsou pojmenované tak, jak má své responzivní třídy/proměnné pojmenované Bootstrap, tedy se suffixem xs, sm, md a lg.

Popis jednotlivých souborů

• variables.less – toto je soubor, který v podstatě vždy upravuji jako první. Přepisuji zde hodnoty výchozích Bootstrap proměnných a také deklaruji vlastní proměnné.
• bootstrap.less – soubor s mírně matoucím názvem. Zde přepisuji CSS pro jednotlivé Bootstrap komponenty. Pokud je CSS u některé komponenty hodně rozsáhlé, pro přehlednost pro ni vytvořím samostatný modul.
• common.less – zde píšu všechno ostatní CSS. A stejně jako u předchozího bodu, pokud se to v zájmu přehlednosti vyplatí, vytvořím pro některé prvky vlastní modul. Běžně to bývá pro hlavičku, patičku, menu, boxy atd.
• responzivní moduly si zaslouží podrobnější představení.

Mobile first

„První pravidlo Media queries je to, že žádná media queries nejsou,“ jak pravil Honza Sládek. A já si poslední dobou vzal jeho slova k srdci. Proto nejprve píšu CSS pro všechny prohlížeče/rozlišení a teprve nakonec přidávám styly pro různá rozlišení, počínaje sm, přes md až po lg. Začnu u sm rozlišení a postupně „přidávám“ až k desktopu. Soubor responsive-xs je naopak pro nejmenší displeje – s mobile first přístupem bývá tento soubor často prázdný, ale občas je potřeba něco definovat jen pro malé displeje. Tolik krátká, leč velmi důležitá odbočka od Bootstrapu.

Závěrem

Tolik tedy o mém pohledu na Bootstrap a na práci s ním. Budu se těšit na vaše komentáře, ve kterých se můžete také podělit o své zkušenosti a workflow, které s Bootstrapem používáte.

Ale co s dalšími a dalšími třídami, které u rozsáhlých projektů přibývají s každým zpracovaným grafickým návrhem? V některých situacích už mi dochází fantazie, když musím **horko těžko vypotit další název třídy**. Podle grafického návrhu je většinou jasné, jakou bude stylovaný element plnit funkci, ale co s podobnými nebo třeba jen lehce změněnými elementy?

Hrušky a Jablka kontra Ovoce

Jako názorný příklad si vezměte tabulku obsahující hrušky. Dostane class="hrusky", nějaké ty styly a hotovo, odjezd. Jenže ejhle, v dalším návrhu je tabulka, která vypadá úplně stejně jako předcházející s hruškami, ale obsahuje jablka. Co s tím? Nechat nelogický název třídy, nebo přepsat na class="jablka"?

Nejlepší by bylo dát oběma tabulkám class="ovoce". Co když to ale z nějakého důvodu (šablona už je nasazená v aplikaci, muselo by se to přepisovat na X místech) nejde? Možná si také říkáte „Hloupý kodér, který nemyslí dopředu“, ale…

Za kolik rohů má kodér nahlížet?

Dobrý kodér by měl určitě za nějaký ten roh dopředu vidět, ale „vocaď pocaď“. Určitě by neměl jen tupě otevřít první péesdéčko a odshora dolů nakódovat. Osobně se mi osvědčilo si nejdříve opravdu důkladně **prohlédnout drátové modely i grafické návrhy a zamyslet se nad nimi**. Chvíle rozjímání nad návrhy, než člověk otevře editor, se mi potom při kódování několikanásobně vrátí.

Ale přeci jen jsem placený za kódování, nikoli za rozjímání, takže někde musí být hranice, kdy musím svoje „co kdyby“ rázně utnout a začít kódovat. **Od jistého okamžiku už je cokdybování kontraproduktivní.** Lehko si s ním vykonstruuji situace, které nikdy nenastanou.

Vrátím-li se tedy k výše uvedenému hruškovému příkladu, pak tedy ano – mohl jsem vědět dopředu, že se může vyskytnout i tabulka s jablky a pojmenovat třídu obecněji. Ale co kdyby se jednou v tabulce objevily třeba okurky? Bramborové knedlíky? Vzducholodě? Vycházkové hole asi takhle dlouhé?

Myslím, že někde u okurek je dobré rozjímání skončit a pojmenovat třídu potraviny, byť by se to v budoucnu mohlo ukázat jako špatné rozhodnutí.

Ono nahlížení za roh se netýká jen takových triviálních věcí, jako jsou názvy tříd. Jsou tu i úvahy typu „A co by se asi stalo, kdyby ten nadpis byl delší než v návrhu?“ nebo „Co když tam **nebude** tenhle box?“ nebo „Co když tam **bude** nějaký box navíc?“

A co vy?

**Máte pod kůží nějaké pojmenovávací konvence?** Jaké názvy tříd používáte? Můžete (musíte) si je vymýšlet sami, nebo vaše firma v coding standards myslela i na HTML a CSS? **Za kolik rohů nahlížíte?** Budu rád za vaše komentáře!