Kan Google uw website wel echt bekijken?

Wat is dat bestand nou eigenlijk

Elke website heeft, of zou moeten hebben, een bestand met de naam robots.txt. U vindt het door achter uw domeinnaam /robots.txt te typen, bijvoorbeeld uwbedrijf.nl/robots.txt. Dit bestand is het eerste dat Google leest voordat het uw site bekijkt. Het staat er in gewone tekst en zegt tegen zoekmachines welke delen van de site ze wel en niet mogen bezoeken.

U kunt het vergelijken met een bordje bij de ingang van een gebouw. Sommige deuren staan open, andere zijn met een simpel briefje afgesloten. Het probleem is dat bedrijven soms per ongeluk het verkeerde briefje ophangen. In plaats van één achterdeur af te sluiten, sluiten ze het hele gebouw af voor bezoekers, inclusief de belangrijkste ruimtes.

Naast de paden die wel of niet bezocht mogen worden, gaat het ook om iets subtielers: de bestanden die de pagina opbouwen. Denk aan CSS, dat zorgt voor de opmaak, en JavaScript, dat zorgt voor beweging en interactie op de pagina. Als robots.txt die bestanden blokkeert, kan Google de pagina wel bezoeken, maar niet goed bekijken. Het ziet dan een kale, kapotte versie van uw site.

Dit hangt nauw samen met een ander controlepunt: of uw kerninhoud ook zonder JavaScript bereikbaar is, zoals wij uitleggen bij de kerninhoud is bereikbaar zonder JavaScript. Beide punten gaan over dezelfde vraag: kan Google uw pagina zien zoals een bezoeker hem ziet, of krijgt Google een onvolledig beeld dat slecht scoort.

Waarom dit meer is dan een technisch detail

Google gebruikt een proces dat renderen heet: de zoekmachine bouwt uw pagina in feite na, precies zoals een browser dat doet, om te zien wat een bezoeker echt te zien krijgt. Dat kan alleen als Google bij alle onderdelen mag die daarvoor nodig zijn. Als CSS of JavaScript geblokkeerd is, ziet Google een kale pagina zonder opmaak, zonder menu, soms zonder de tekst die met scripts wordt ingeladen.

Het gevolg is dat Google verkeerd inschat waar uw pagina over gaat. Een pagina die er voor bezoekers prima uitziet, kan voor Google onbegrijpelijk of leeg lijken. Dat is geen kwestie van net iets minder goed scoren. Het is een kwestie van niet meegenomen worden, terwijl u niets fout deed aan de inhoud zelf.

Er is een verschil tussen een pagina die niet bestaat en een pagina die wel bestaat maar onbereikbaar is gemaakt. Dat raakt ook aan andere punten in onze meetlijst, zoals de vraag of een verwijderde pagina netjes een 404-status teruggeeft, zoals wij bespreken bij de 404-pagina zelf is behulpzaam. In beide gevallen gaat het om duidelijkheid: laat aan Google zien wat wel en niet bedoeld is om gevonden te worden.

Hoe u zelf checkt of het bij u in orde is

Typ uw domeinnaam gevolgd door /robots.txt in de adresbalk van uw browser. Er verschijnt een simpele lijst met regels, meestal met woorden als 'Disallow' gevolgd door een pad. Disallow betekent: dit pad mag niet bezocht worden. Kijk of daar iets staat dat u niet verwacht, zoals een schuine streep alleen, wat betekent dat de hele site is afgesloten.

Let vooral op regels die verwijzen naar mappen met namen als /wp-content/, /assets/, /css/ of /js/. Dit zijn vaak precies de mappen waar de opmaak en interactie van uw site in staan. Staan die geblokkeerd, dan is de kans groot dat Google uw pagina's niet goed kan renderen, ook al lijkt de rest van het bestand onschuldig.

Google Search Console, een gratis dienst van Google voor website-eigenaren, heeft een test waarmee u een specifieke pagina kunt controleren op renderproblemen. U ziet daar een voorbeeld van hoe Google uw pagina waarneemt. Ziet dat er kaal of kapot uit terwijl de pagina in uw browser er prima uitziet, dan is dat een duidelijk signaal dat er iets misgaat bij het laden van CSS, JavaScript of afbeeldingen.

Twijfelt u of een bepaald pad expres is uitgesloten of per ongeluk, overleg dan met wie uw website heeft gebouwd. Sommige blokkades zijn bewust en verstandig, zoals het afsluiten van een intern zoekresultaat, iets waar wij apart op ingaan bij interne zoekresultaatpagina's op noindex. Andere blokkades zijn simpelweg fouten uit een standaardinstelling die nooit is nagekeken.

Wat het kost als dit niet in orde is

Als robots.txt belangrijke paden blokkeert, sluit u zonder het te merken delen van uw site af voor Google. Dat kunnen productpagina's zijn, blogartikelen, of zelfs de hele site na een verhuizing naar een nieuw systeem. Dit gebeurt vaker dan mensen denken, vooral na een website-vernieuwing, waarbij een instelling die bedoeld was voor de testomgeving per ongeluk blijft staan op de echte site.

Het venijnige is dat u er niets van merkt in uw dagelijkse gebruik van de site. De pagina's laden gewoon, bezoekers die de link direct krijgen kunnen er nog steeds komen. Alleen het verkeer via zoekmachines droogt langzaam op, zonder duidelijke aanleiding. Veel ondernemers zoeken de oorzaak dan in de inhoud of de concurrentie, terwijl het probleem in een technisch bestand zit dat ze nog nooit hebben geopend.

Wanneer alleen CSS en JavaScript geblokkeerd zijn, is het effect subtieler maar niet minder schadelijk. Uw pagina's blijven wel vindbaar, maar Google beoordeelt ze op basis van een onvolledig beeld. Tekst die door een script wordt ingeladen, telt dan misschien niet mee. Een pagina die er voor u prima uitziet, wordt door Google beoordeeld als arm aan inhoud, met alle gevolgen voor uw positie in de zoekresultaten.

Herstel is meestal geen kwestie van maanden werk. Vaak gaat het om een paar regels aanpassen in een bestand. Het punt is dat u het probleem eerst moet herkennen. Zonder controle blijft een blokkade soms jarenlang onopgemerkt bestaan, gewoon omdat niemand er nog naar keek nadat de site voor het laatst is aangepast.

Wat er moet gebeuren om dit op orde te krijgen

Het uitgangspunt is simpel: robots.txt mag alleen paden blokkeren die u bewust wilt uitsluiten, zoals een inlogpagina voor beheerders of een winkelwagentje dat toch nooit in zoekresultaten hoort te staan. Alles wat bijdraagt aan hoe de pagina eruitziet of werkt, moet toegankelijk blijven. Dat is het hele principe achter dit controlepunt: niet dichttimmeren uit voorzorg, maar gericht afsluiten waar dat nodig is.

Laat dit bestand controleren als onderdeel van een breder overzicht van wat wel en niet geïndexeerd hoort te worden. Dat overzicht, een indexatiematrix per paginatype, brengt in kaart welke pagina's zichtbaar moeten zijn voor Google en welke bewust niet, zoals wij toelichten bij een indexatiematrix per paginatype. Robots.txt is dan het instrument waarmee die keuzes worden uitgevoerd, niet de plek waar die keuzes worden bedacht.

Controleer dit bestand niet alleen bij de bouw van de site, maar ook na elke grote wijziging: een verhuizing naar een ander systeem, een nieuwe website-bouwer, of een herstructurering van de site. Dit zijn precies de momenten waarop instellingen per ongeluk worden meegenomen uit een testomgeving. Een korte controle achteraf voorkomt dat een tijdelijke instelling permanent wordt.

Denk er ook aan dat robots.txt niet op zichzelf staat. Het is nauw verbonden met andere signalen die u aan Google geeft, zoals de instructie op paginaniveau via een noindex-tag, waarover meer bij noindex via meta robots of de X-Robots-Tag. Beide moeten elkaar niet tegenspreken. Een pagina die u wilt tonen mag niet via het ene kanaal worden opengezet en via het andere alsnog worden geblokkeerd.