Over crawlen, indexeren en robots.txt voor WordPress

Crawlen is de activiteit van Google en andere zoekmachines waarbij ze openbaar beschikbare pagina’s ontdekken. Hiervoor worden softwareprogramma’s gebruikt die we ‘webcrawlers’ of ‘spiders’ noemen. De webcrawlers volgen dezelfde links waar jij op klikt tijdens het surfen op websites. Zo worden nieuwe pagina’s ontdekt. De software besteedt extra aandacht aan nieuwe sites, wijzigingen in bestaande sites en dode links.

Al deze pagina’s worden door Google georganiseerd in een grote index. Dit noemen we indexeren. De pagina’s in de index kunnen als zoekresultaat getoond worden aan bezoekers van Google of andere zoekmachines. Bij een zoekopdracht in Google zoek je dus niet iets rechtstreeks op in het web, maar zoek je in de index van Google.

Meer informatie:

Crawlen en indexeren, Google Inside Search
Robots.txt Specifications, Google Developers
Robots meta tag and X-Robots-Tag HTTP header specifications

Crawler richtlijnen

Via een robots.txt bestand kun je richtlijnen doorgeven hoe bots van Google en andere zoekmachines je website moeten crawlen. Door het gebruik van ‘Disallow:’ kun je webcrawlers namelijk vertellen welke onderdelen van de website ze niet mogen crawlen.

Het robots.txt protocol is ontstaan in 1994. Webcrawlers houden rekening met dit bestand, maar slechts tot op zekere hoogte. Je zou wellicht denken dat het uitsluiten van bepaalde pagina’s en bestanden in robots.txt voldoende is om (een deel) van een website uit de index van Google te houden. Dat is echter niet het geval. Als je een pagina of bestand uitsluit voor de webcrawlers in robots.txt, maar de URL nog steeds gevonden wordt op andere websites, kunnen zoekmachines deze externe URL nog steeds crawlen en opnemen in hun index.

Als je dus echt wilt voorkomen dat iets zichtbaar is in de zoekmachines, dan is robots.txt niet de beste oplossing. Een aantal voorbeelden waaruit blijkt dat robots.txt niet voldoende is vind je in het artikel Serious Robots.txt Misuse & High Impact Solutions. Eén voorbeeld daarvan is de website WordPress.com. Onderstaande is zichtbaar in de robots.txt van WordPress.com.

Er zijn echter een heleboel pagina’s die linken naar de URL http://wordpress.com/next/. Het gebruik van disallow in het robots.txt bestand is dan ook niet voldoende gebleken om dit resultaat uit Google te mijden, zie hieronder.

De titel en de URL zijn gewoon zichtbaar in Google. Alleen de beschrijving laat Google nog achterwege vanwege de richtlijnen in het robots.txt bestand.

Google legt heel goed uit wat je moet doen om er zeker van te zijn dat een resultaat uit de zoekresultaten blijft, zie de uitleg Metatags gebruiken om de toegang tot uw site te blokkeren.

Als u er zeker van wilt zijn dat de inhoud van een pagina niet aan de index van Google wordt toegevoegd, zelfs wanneer andere pagina’s ernaar verwijzen, gebruikt u de noindex-metatag. Zolang de Googlebot de pagina ophaalt, zal deze de noindex-metatag herkennen en voorkomen dat de pagina wordt weergegeven in de webindex.

En dat is meteen het bruggetje naar de Index richtlijnen, lees dus snel verder!

Index richtlijnen

De index richtlijnen bepalen écht hoe inhoud zichtbaar (of onzichtbaar) is in de zoekresultaten. Je kunt dit aan Google of andere zoekmachines kenbaar maken door gebruik te maken van een robots meta tag voor HTML pagina’s of door een X-Robots-Tag in de HTTP header. Het voordeel van de HTTP header ten opzichte van de robots meta tag is dat het ook voor andere documenten gebruikt kan worden, terwijl de robots meta tag alleen geschikt is voor HTML pagina’s.

Door het toevoegen van de ‘noindex’ richtlijn aan de robots meta tag voorkom je écht dat de pagina wordt getoont in de zoekresultaten.

Robots meta tags en X-Robots-Tag HTTP headers worden ontdekt wanneer een URL wordt gecrawled. Je mag dus nooit de webcrawler via een robots.txt bestand verbieden de URL te crawlen, omdat de ‘noindex’ informatie dan niet gevonden kan worden! In eigenlijk alle gevallen is het gebruik van ‘noindex’ dus een betere manier om URL’s uit de zoekresultaten te houden. Omdat je de webcrawler tevens niet verbiedt om de inhoud te lezen kunnen (inbound) links op die pagina’s nog steeds worden ontdekt door de webcrawler en kan autoriteit/PageRank/link juice doorgegeven worden aan die pagina’s.

Robots meta tags and X-Robots-Tag HTTP headers are discovered when a URL is crawled. If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving directives will not be found and will therefore be ignored. If indexing or serving directives must be followed, the URLs containing those directives cannot be disallowed from crawling.

Zoekmachines ontmoedigen je site te indexeren via WordPress

In het korte artikel Virtueel robots.txt bestand in WordPress liet ik al zien dat WordPress de mogelijkheid biedt om zoekmachines te ontmoedigen je website te ‘indexeren’. Wat WordPress dan doet is het virtuele robots.txt bestand wijzigen naar onderstaande.

User-agent: *
Disallow: /

Dit houdt simpelweg in dat de website dus niet door Google gecrawled mag worden. We weten inmiddels echter dat dit helemaal niet voldoende is om de site uit de zoekresultaten te houden.

Een goed voorbeeld is dat veel webdevelopers gebruik maken van een staging area waar ze wijzigingen aan websites eerst uitproberen voordat ze dit toepassen op de livesite. Vaak word hier gebruik gemaakt van een subdomein zoals dev.domeinnaam.nl of staging.domeinnaam.nl. Die wil je natuurlijk niet in de zoekresultaten zien! Ik geef hieronder twee voorbeelden waarbij dat vinkje in WordPress dus zeker niet geholpen heeft!

Zoals eerder uitgelegd is dit het risico van een robots.txt bestand. Dit wordt ook nog eens uitgelegd via het Google helpartikel Pagina’s blokkeren of verwijderen met een robots.txt-bestand.

Hoewel Google de inhoud van pagina’s die zijn geblokkeerd door robots.txt niet crawlt of indexeert, kunnen we de URL’s wel indexeren als we deze op andere webpagina’s tegenkomen. Hierdoor kunnen de URL van de pagina en mogelijk andere openbare informatie, zoals ankertekst in links naar de site of de titel van het Open Directory Project (www.dmoz.nl), worden weergegeven in de zoekresultaten van Google.

Nou weet ik mijn god niet hoe Google de URL’s zichtbaar in bovenstaande afbeeldingen gevonden heeft, maar Google weet alles toch ;-). Matt Cutts legt in onderstaande video uit 2009 nog eens haarfijn hetzelfde uit.

Het is interessant dat WordPress echter niet alleen de bovengenoemde robots.txt aanmaakt bij het ontmoedigen van zoekmachines om de website te indexeren, ze voegen ook de robots meta tag toe aan de HTML van alle pagina’s.

We weten echter inmiddels dat deze helemaal niet door Google ontdekt kan worden omdat de robots.txt de zoekmachine verhinderd de pagina te crawlen. Dit heeft dus helemaal geen effect. Ik snap dan ook niet waarom WordPress de robots.txt niet gewoon weglaat, dan zou altijd beter zijn! Ik ben een forumbericht gestart hierover, zie Discourage search engines bug. De oplossing is dus je eigen robots.txt te plaatsen in de root van je website waarbij je de zoekmachines dus wel toestaat om je website te crawlen.

De conclusie is dat de virtuele robots.txt van WordPress niet gewenst is. De oplossing is dat je zelf een robots.txt aanmaakt in de root van je website, waarbij je de zoekmachine gewoon toestaat om je website te crawlen, zodat deze de robots meta tag kan ontdekken en daardoor de pagina dus niet opneemt in de zoekresultaten. Met onderstaande geef je aan dat je gehele website gecrawled mag worden.

User-agent: *
Disallow:

Of zijn er toch nog situaties te bedenken om het crawlen te verbieden via een robots.txt bestand? Lees hieronder hoe je complete robots.txt er uit moet zien!

Het handmatige robots.txt bestand

Joost merkt in zijn artikel WordPress robots.txt Example terecht op dat het door WordPress geadviseerde robots.txt bestand foutief is. In dat bestand zie je een hele rits met blokkades voor de zoekmachines, waarvan het meeste verouderd is. Een paar zaken die wel actueel zijn worden uitgelicht door Joost.

There are two other sections which are blocked in the suggested robots.txt, /*?, which blocks everything with a question mark and as such all search results, and */feed/, which blocks all feeds. The first is not a good idea because if someone were to link to your search results, you wouldn’t benefit from those links.

A better solution would be to add a  tag to those search results pages, as it would prevent the search results from rankings but would allow the link “juice” to flow through to the returned posts and pages. This is what my WordPress SEO plugin does as soon as you enable it. It also does this for wp-admin and login and registration pages.

Voor zover ik weet worden met de wp-admin en login pagina’s hetzelfde bedoeld, en ik zie dat WordPress nu zelf al toevoegt aan deze pagina’s. Daar is de WordPress SEO plugin dus niet meer specifiek voor nodig.

Uiteraard heb ik ook even gecontroleerd of WordPress dit al automatisch doet voor de zoekpagina’s, en dat is helaas nog niet het geval. Maar zoals Joost beloofd lost zijn WordPress SEO plugin dit op, en dat blijkt na controle ook daadwerkelijk zo te zijn.

En waarom de feed in zijn geheel niet geblokkeerd moet worden legt Joost ook nog even haarfijn uit.

Blocking /feed/ is a bad idea because an RSS feed is actually a valid sitemap for Google. Blocking it would prevent Google from using that to find new content on your site.

Er blijkt echter één deel van de website te zijn die Joost wel blokkeerd voor de zoekmachine.

I block the plugins directory because some plugin developers have the annoying habit of adding index.php files to their plugin directories that link back to their websites. For all other parts of WordPress, there are better solutions for blocking.

Samenvattend is onderstaande dus het ideale robots.txt bestand.

User-Agent: *
Disallow: /wp-content/plugins/

Overigens had Joost de kern van dit verhaal ook reeds benoemd in een artikel uit 2009, Preventing your site from being indexed, the right way, waar hij zijn verbazing ook al uitspreekt dat mensen robots.txt hiervoor blijven gebruiken.

Geblokkeerde JS en CSS door het ‘ideale robots.txt’ bestand

Het ideale robots.txt bestand blijkt helaas ook een beperkte houdbaarheidsdatum te hebben. Vandaag, 2 augustus 2014, las ik wederom een artikel van Joost, Google Panda 4, and blocking your CSS & JS. Uit dit artikel heb ik geleerd dat Google in Google Webmaster Tools een nieuwe tool heeft geïntroduceerd, namelijk Fetch as Google.

Zoals je kunt lezen als je op voorgaande link klikt, laat deze tool exact aan ons zien hoe Googlebot onze site ziet! Zie onderstaande afbeelding hoe dat er momenteel uitziet voor een klant van mij.

Voordat je er aan voorbij gaat, de preview die Google toont is exact hoe ik het in mijn browser zie. Dit is bijzonder! De Googlebot (de spider/webcrawler van Google) wordt net als andere webcrawlers vaak bestempeld als ‘domme gebruiker’ omdat ze alleen in staat zouden zijn om de tekstuele content uit de HTML van je pagina te ‘lezen’. Google blijft zichzelf echter steeds verbeteren en is nu dus in staat veel meer van het web te begrijpen en ziet onze websites dus nagenoeg zoals wij ze ook zien in onze moderne browsers! Google legt dit haarfijn uit in hun artikel Understanding web pages better.

Traditionally, we were only looking at the raw textual content that we’d get in the HTTP response body and didn’t really interpret what a typical browser running JavaScript would see. When pages that have valuable content rendered by JavaScript started showing up, we weren’t able to let searchers know about it, which is a sad outcome for both searchers and webmasters.

Als we de Googlebot willen toestaan om onze website te zien zoals wij de website ook zien in onze browser, is het dus belangrijk dat we CSS en Javascript bestanden niet voor Googlebot blokkeren. De kans is groot dat je dit wel (onbewust) hebt gedaan via je robots.txt, waarover later meer. Mocht je toch besluiten deze bestanden te blokkeren, dan hier uit hetzelfde artikel toch echt de redenen om dit niet te doen! Zoals je leest kan dit een negatief effect hebben op de zoekresultaten voor jouw website.

Sometimes things don’t go perfectly during rendering, which may negatively impact search results for your site. Here are a few potential issues, and – where possible, – how you can help prevent them from occurring:

• If resources like JavaScript or CSS in separate files are blocked (say, with robots.txt) so that Googlebot can’t retrieve them, our indexing systems won’t be able to see your site like an average user. We recommend allowing Googlebot to retrieve JavaScript and CSS so that  your content can be indexed better. This is especially important for mobile websites, where external resources like CSS and JavaScript help our algorithms understand that the pages are optimized for mobile.
• If your web server is unable to handle the volume of crawl requests for resources, it may have a negative impact on our capability to render your pages. If you’d like to ensure that your pages can be rendered by Google, make sure your servers are able to handle crawl requests for resources.
• It’s always a good idea to have your site degrade gracefully. This will help users enjoy your content even if their browser doesn’t have compatible JavaScript implementations. It will also help visitors with JavaScript disabled or off, as well as search engines that can’t execute JavaScript yet.
• Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.
• Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.

Terug naar het artikel Rendering pages with Fetch as Google. Met alle voorgaande uitleg weten weten we nu het doel van de tool. Ook weten we dat als je bijvoorbeeld Javascript of CSS blokkeert in robots.txt dat Googlebot dus geen of een beperkte website kan laten zien in de preview.

Googlebot follows the robots.txt directives for all files that it fetches. If you are disallowing crawling of some of these files (or if they are embedded from a third-party server that’s disallowing Googlebot’s crawling of them), we won’t be able to show them to you in the rendered view.

Maar eigenlijk moet je het andersom zeggen, jij blokkeert Google om jouw website te crawlen zoals een normale gebruiker (jij en ik) de website ook zien in een moderne browser. En Google adviseert dus ook hier verstandig mee om te gaan.

We recommend making sure Googlebot can access any embedded resource that meaningfully contributes to your site’s visible content, or to its layout. That will make Fetch as Google easier for you to use, and will make it possible for Googlebot to find and index that content as well. Some types of content – such as social media buttons, fonts or website-analytics scripts – tend not to meaningfully contribute to the visible content or layout, and can be left disallowed from crawling.

Ter extra ondersteuning nog even een Youtube video met Matt Cutts waar dit in behandeld wordt: SMX Advanced 2014 – Google’s Matt Cutts You&A Keynote.

Terug naar de afbeelding die ik hierboven met jullie gedeeld heb. Je ziet dat Google diverse meldingen geeft van CSS en Javascript bestanden waar de Googlebot geen toegang toe heeft. Dit komt uiteraard omdat we de complete plugins folder in ons handmatige robots.txt bestand geblokkeerd hebben. Omdat we dit met een goede reden hebben gedaan, willen we dat zo houden. Om Googlebot echter niet te hinder gaan we de specifieke CSS en JS bestanden echter wel toestaan te crawlen, gewoon door meer specifiek te zijn. Het robots.txt komt er als volgt uit te zien:

User-Agent: *
Disallow: /wp-content/plugins/
Allow: /wp-content/plugins/sitepress-multilingual-cms/res/css/language-selector.css
Allow: /wp-content/plugins/jetpack/modules/widgets/widgets.css
Allow: /wp-content/plugins/tablepress/css/default.min.css
Allow: /wp-content/plugins/wp-views/embedded/res/css/wpv-pagination.css
Allow: /wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox-1.3.6.pack.css
Allow: /wp-content/plugins/jetpack/modules/sharedaddy/sharing.css
Allow: /wp-content/plugins/wp-views/embedded/res/js/i18n/jquery.ui.datepicker-nl.js
Allow: /wp-content/plugins/wp-views/embedded/res/js/wpv-pagination-embedded.js
Allow: /wp-content/plugins/sitepress-multilingual-cms/res/js/sitepress.js
Allow: /wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox-1.3.6.pack.js
Allow: /wp-content/plugins/easy-fancybox/jquery.easing.pack.js

Uiteraard zijn er diverse mogelijkheden om het aantal JS of CSS bestanden te beperken (zoals Minify), en is het natuurlijk altijd verstandig om te beoordelen of de JS en CSS die plugins gebruiken en implementeren in je website wel daadwerkelijk nodig zijn. Maar dat is om iets te bespreken in een nieuw blogartikel!