Staging in Google: vind en sluit de testomgeving af

Veel kmo's zetten op de testomgeving een robots.txt met een algemene blokkade en gaan ervan uit dat het probleem opgelost is. Dat klopt maar half. Volgens de documentatie van Google (Introductie tot robots.txt) dient robots.txt vooral om het crawlverkeer te beheren, en niet om een pagina uit de Google-resultaten te houden. Een geblokkeerde pagina kan met alleen de URL (zonder beschrijving) in de resultaten verschijnen als andere plekken ernaar linken.

Daarnaast is robots.txt een verzoek, geen slot. Googlebot en andere betrouwbare crawlers volgen het, maar andere bots en gewone browsers doen dat niet. Dat betekent twee dingen voor jou:

• Een browsercontrole bewijst niets over crawltoegang van Google, want je browser negeert robots.txt.
• Alles wat vertrouwelijk is, hoort achter authenticatie, zoals een wachtwoord. Dat is ook wat de bron aanraadt voor privébestanden.

Een robots.txt-blokkade op staging is dus hooguit een extra laag, nooit de beveiliging zelf.

Begin met een lijst van alle omgevingen die ooit voor je site zijn aangemaakt. Vraag je webbouwer of hoster naar subdomeinen, aparte domeinnamen, tijdelijke previewlinks en mappen op het hoofddomein. Vul de lijst aan met wat je zelf kunt vinden.

1. Zoek op je eigen merk en domein. Probeer in Google zoekopdrachten met site: gevolgd door je domein en kijk naar subdomeinen of afwijkende titels die op een test lijken. Een zoekopdracht toont niet alles, dus een leeg resultaat is geen bewijs van afwezigheid.
2. Raadpleeg Search Console. Controleer in elke eigendomsverificatie die je hebt welke URL's Google kent, en kijk of er hostnamen opduiken die je niet herkent. Waar exact je dit vindt, hangt van de huidige interface af; check dat in je account.
3. Zoek in je eigen content. Doorzoek je livesite, sitemaps, nieuwsbrieven en offertemails op verwijzingen naar de testhost. Eén verdwaalde interne link of canonical naar staging is genoeg om die omgeving bekend te maken.
4. Vraag leveranciers. Bureaus delen previewlinks vaak met klanten; vraag welke nog actief zijn.

Noteer per gevonden host de volledige URL en wie hem beheert.

Test elke gevonden omgeving op drie vragen: kan een buitenstaander de pagina openen, geeft de omgeving signalen over indexering, en weet Google er al van? Gebruik onderstaand blad om per host te beslissen.

Bij twijfel kies je de strengste actie: eerst de toegang dichtzetten, dan pas analyseren wat er al zichtbaar was.

De volgorde telt, omdat sommige maatregelen elkaar tegenwerken. De documentatie noemt noindex of wachtwoordbeveiliging als manieren om een pagina uit Google te houden. Voor een testomgeving is wachtwoordbeveiliging de logische eerste keuze, omdat ze ook mensen en andere bots buiten houdt. Een sluitend stappenplan:

1. Zet authenticatie aan voor de hele host, bij voorkeur op serverniveau zodat ook afbeeldingen, scripts en PDF's beschermd zijn. Je hoster of webbouwer weet welke methode je platform ondersteunt.
2. Wacht niet met afsluiten op noindex. Google kan een noindex alleen lezen als de pagina bereikbaar is, en bij een login ziet Googlebot die aanwijzing niet meer. Laat daarom de toegang niet open om noindex te laten oppikken. Heb je een bekende URL snel nodig uit de resultaten, overweeg dan een verwijderverzoek in Search Console; controleer in je eigen account of dat voor jouw situatie beschikbaar is.
3. Blokkeer niet in robots.txt zolang je noindex nodig hebt. Een crawler die de pagina niet mag ophalen, kan de noindex ook niet lezen.
4. Laat later de oude URL's vanzelf wegvallen of vraag verwijdering aan. Hoe snel Google dit verwerkt, is niet te voorspellen.

Zorg dat de configuratie van staging niet per ongeluk naar de livesite verhuist bij een release. Een noindex of login die op productie belandt, is een andere en even vervelende fout.

Een wijziging is pas klaar als je ze hebt getest van buitenaf. Doe dit in een privévenster of op een ander netwerk, niet vanuit je eigen ingelogde sessie.

• Toegang: open de hoofd-URL, een diepere pagina, een afbeelding en een PDF van de testhost. Verwacht overal een loginvraag of weigering.
• Bronbestanden: controleer in de HTTP-respons dat statuscode en eventuele robots-header of meta-tag zijn wat je bedoeld had.
• Google-zicht: gebruik, als je voor de testhost eigendom in Search Console hebt, de URL-inspectie voor een bekende testpagina en kijk wat Google rapporteert over crawlen en indexering. Zonder eigendom of achter een login is dit beperkt bruikbaar. Een browsertest vervangt dit niet, want je browser volgt robots.txt niet.
• JavaScript-sites: Google verwerkt pagina's in crawlen, renderen en indexeren, en rendert geen JavaScript van geblokkeerde pagina's of bestanden, zoals beschreven in de JavaScript-SEO-basis van Google. Een staging die als app-shell leeg lijkt in de broncode, toont de inhoud pas na rendering, dus beoordeel bij zulke sites ook de gerenderde versie. Let op: is de pagina geblokkeerd of afgeschermd, dan wordt ze niet gerenderd.
• Opvolging: noteer datum en uitkomst, en herhaal de controle enkele weken later. Een vaste termijn voor verdwijning uit Google kan niemand beloven.

Een fictieve situatie, uitsluitend als invoer en verwachte controles. Een webshop laat een bureau een nieuwe versie bouwen op een subdomein. Het bureau stuurt de klant een previewlink in een mail; na oplevering blijft het subdomein staan.

Invoer bij de overdracht: hostnaam van de testomgeving, het bureau als beheerder, geen authenticatie, een robots.txt met algemene blokkade, een canonical in de testpagina's die naar de testhost zelf wijst, en een nog actieve previewlink in een mail.

Verwachte controles:

1. Open de host in een privévenster en noteer of een loginvraag verschijnt.
2. Zoek de host op in Search Console en met een site:-zoekopdracht; noteer wat zichtbaar is, wetende dat dit onvolledig kan zijn.
3. Laat het bureau serverauthenticatie instellen en de mailslink intrekken.
4. Laat bevestigen dat productiepagina's niet per ongeluk de canonical of noindex van staging overnemen.
5. Inspecteer een testpagina met URL-inspectie en herhaal de controle na enkele weken.

Wil je ook snel zien welke zichtbare signalen je livesite uitzendt? Bekijk de publieke signalen van je eigen website via Marketing Scan. Een publieke scan meet alleen wat van buitenaf zichtbaar is en vervangt niet de beheerderscontroles in deze gids.