Gevoelige paden in robots.txt

Hoe deze controle werkt

Scanaris downloadt je /robots.txt en controleert eerst dat het een echt robots-bestand is: het antwoordt 200, is geen HTML en bevat minstens één richtlijn (User-agent, Disallow, Allow of Sitemap). Daarna loopt hij elke Disallow:-regel langs en kijkt of het pad een van deze indicatoren bevat: wp-admin, phpmyadmin, /admin, backup, .git, .env, /private, /secret, dump, .sql, password of credential. Komt er een overeen, dan opent hij een bevinding met lage ernst en de gevonden paden. De lijst is bewust kort: woorden als test, old, tmp of logs komen voor in volkomen legitieme robots-bestanden en gaven valse positieven.

Waarom dit belangrijk is

robots.txt is per definitie openbaar: iedereen kan het lezen, en het is zelfs een van de eerste bestanden waar een verkenningstool naar kijkt. Wanneer je Disallow: /backups/ of Disallow: /oude-admin/ schrijft, verberg je die paden niet; je wijst ze aan voor wie ze zoekt, met de extra garantie dat je ze belangrijk vindt. Google zal ze niet crawlen, maar een aanvaller leest robots niet om het te gehoorzamen, maar om te weten waar hij heen moet. Het is een bevinding met lage ernst omdat een pad vermelden het niet toegankelijk maakt; het probleem ontstaat wanneer het vermelde pad bovendien onbeschermd is.

Hoe je het oplost

• Haal de paden die je niet wilt aankondigen uit robots.txt. Wil je niet dat Google een privégedeelte indexeert, dan is de juiste aanpak dat dat gedeelte om inloggen vraagt; wat achter authenticatie zit, wordt toch niet geïndexeerd.
• Moet een bereikbare pagina uit de zoekmachines blijven zonder hem aan te kondigen, gebruik dan de header X-Robots-Tag: noindex of de robots-meta op die pagina. Zoekmachines respecteren dat en het staat niet in een openbaar bestand.
• Bescherm het pad echt. Een paneel op /admin heeft authenticatie nodig, geen regel in robots. Een map /backups/ hoort helemaal niet in de openbare map; de controles gevoelige bestanden en mapoverzicht dekken die gevallen.
• WordPress: de virtuele robots die het genereert bevat standaard Disallow: /wp-admin/. Dat is niet ernstig, omdat wp-admin al om inloggen vraagt en noindex stuurt; je kunt het laten staan of robots vervangen door een eigen bestand zonder die regel. Wat telt, is dat de login sterke wachtwoorden, een pogingenlimiet en, als het kan, tweestapsverificatie heeft.

Een gezonde robots.txt is meestal kort: een User-agent: *, misschien een paar Disallow-regels voor interne zoekopdrachten of parameters, en de regel Sitemap:. Heeft de jouwe twintig regels met "privé"-paden, dan doet hij het werk van een rechtensysteem, en slecht.

Controleer of het opgelost is

curl -s https://jouwdomein.nl/robots.txt | grep -iE "^disallow:.*(admin|phpmyadmin|backup|\.git|\.env|private|secret|dump|\.sql|password|credential)"

Er mag niets uitkomen. En voor elk pad dat je hebt verwijderd, controleer je dat het echt om authenticatie vraagt of 404 teruggeeft:

curl -s -o /dev/null -w "%{http_code}\n" https://jouwdomein.nl/admin/

Veelgestelde vragen

Als ik /admin uit robots.txt haal, gaat Google het dan indexeren?

Als /admin om inloggen vraagt, ziet Google alleen het inlogscherm, en dat scherm draagt normaal noindex. Vraagt het niet om inloggen, dan is het probleem niet de indexering, maar dat je paneel open staat.

Kan ik alles blokkeren en alleen het openbare vermelden?

Voor een site die organisch verkeer wil, nee: alles blokkeren met Disallow: / haalt hem uit de zoekmachines. Wil je het crawlen sturen, dan zorgt de controle robots en sitemap ervoor dat je jezelf niet blokkeert.

En AI-bots?

GPTBot, ClaudeBot en consorten blokkeren of toelaten is een aparte zakelijke beslissing en hoort in hetzelfde bestand. Het heeft niets te maken met deze controle, die alleen naar gevoelige paden kijkt.