Academy
Staging-omgevingen beschermen in het kort uitgelegd

Voorkom gênante situaties en zorg ervoor dat jouw staging-omgeving goed beveiligd is.

De beste manier om dit te doen is door middel van HTTP-authenticatie.

Is jouw staging-omgeving al geïndexeerd door zoekmachines? Geen probleem. Met deze handleiding leer je hoe je dit snel en effectief ongedaan kunt maken.

We zien het maar al te vaak gebeuren: Staging- of productie-omgevingen met websites die nog niet af zijn, maar iedereen kan ze zien. En vaak worden ze ook nog eens geïndexeerd door zoekmachines!

Geloof je het niet?

Kijk eens naar deze query – geïnspireerd door by Peter Nikolow’s tweet (volg hem op Twitter, hij is grappig en slim!).

Waarom toegankelijke staging-omgevingen een slechte zaak zijn

Of liever gezegd, een dubbel-slechte zaak: slecht vanuit zowel een zakelijk als SEO oogpunt.

Het zakelijke oogpunt

Wil je dat anderen je “lorem ipsum” -inhoud zien en daarom lachen, of zelfs lezen over een enorme aankondiging zoals een overname of rebranding die geheim had moeten worden gehouden tot de nieuwe site werd gelanceerd?

Het is onprofessioneel en bovendien is het niet erg slim. Het is zelfs een verkooptactiek voor bepaalde bureaus: ze zoeken naar andere bureaus die deze fouten maken en pitchen hun klanten vervolgens, zo gebruikmakend van de gênante situatie.

Het SEO oogpunt

Naast de gêne kan een staging-omgeving die is geïndexeerd door zoekmachines, leiden tot duplicate content problemen wanneer de staging-omgeving en de productieomgeving sterk op elkaar lijken.

Het hebben van toegankelijke en geïndexeerde staging-omgevingen is totaal onnodig, omdat het gemakkelijk te voorkomen is. In dit artikel laten we je zien hoe je dit moet doen, welke methoden je kunt gebruiken en wat je moet doen als uw staging-omgeving al is geïndexeerd.

Vanaf nu, wanneer we verwijzen naar staging-omgevingen, kunnen we het hebben over zowel development- als staging-omgevingen.

Wat zijn development- en staging omgevingen?

Wanneer je werkt aan een geheel nieuwe website of nieuwe functionaliteit, doe je dat niet alleen op jouw live website (vaak jouw “productieomgeving” genoemd), omdat websites gemakkelijk kapot te krijgen zijn. Het is een goede gewoonte om met verschillende, afzonderlijke omgevingen te werken waar je nieuwe functionaliteit ontwikkelt en test.

Dus welke verschillende omgevingen zijn er naast een productieomgeving?

  • Development omgeving: dit is waar developers hun code aanvankelijk testen. Vaak doen ze dit op hun lokale machines, dus als dat het geval is, is er helemaal geen gevaar dat deze omgeving toegankelijk is voor anderen en wordt geïndexeerd door zoekmachines. Als het niet lokaal wordt bewaard, maar in plaats daarvan bijvoorbeeld op eendev.example.com-subdomein, bestaat het risico dat het voor anderen toegankelijk is en wordt geïndexeerd.
  • Staging omgeving (vaak ook de “test omgeving” genoemd): dit is waar releases worden gestaged en nieuwe functionaliteit wordt getest voor een release. Nieuwe inhoud wordt hier gepubliceerd, zodat deze kan worden gecontroleerd om er zeker van te zijn dat het eruit ziet zoals het bedoelt is. Staging-omgevingen worden vaak niet lokaal uitgevoerd: verschillende teamleden moeten er gemakkelijk toegang toe hebben en bevinden zich daarom meestal op een subdomein of een ander domein.

Pro-tip: aangezien je over het beveiligen van staging-omgevingen leest, is het waarschijnlijk dat je binnenkort een website-migratie gaat doen. Om probleemloos te migreren, lees onze website migratie handleiding voor websites om ervoor te zorgen dat je cruciale stappen in het migratieproces niet vergeet!

Beveiliging door middel van Security through obscurity is geen haalbare strategie

Niemand iets vertellen over uw “geheime” staging-omgeving is een geval van “security through obscurity”. Het is geen haalbare strategie om te gebruiken. Vooral niet als de enige laag van bescherming.

Wat als iemand per ongeluk een link publiceert naar de staging-omgeving? Of wat code naar productie zet die per ongeluk canonieke of hreflang-verwijzingen naar de staging-omgeving bevat?

Dit zorgt niet alleen voor problemen in jouw productieomgeving, het leidt ook tot zoekmachines die de spoor van jouw staging-omgeving oppikken. En ze zullen het in de wachtrij plaatsen om te crawlen, tenzij je het hen onmogelijk maakt toegang te krijgen tot de staging-omgeving, of voor hun te volgen regels instelt.

Hoe bescherm je jouw development- en staging-omgevingen

Nu is het duidelijk waarom je je development- en staging-omgevingen moet beschermen. Maar hoe doe je het? Er zijn meerdere manieren om dit aan te pakken, maar welke is het beste?

We zullen de voor- en nadelen van elke methode bespreken, rekening houdend met:

  • Gebruiksvriendelijkheid: de mate waarin de methode geen extra ongemak oplevert.
  • Toegang door derden: de mate waarin de methode voorkomt dat derden toegang krijgen tot een omgeving.
  • SEO-vriendelijkheid: de mate waarin de methode voorkomt dat zoekmachines een omgeving indexeren.
  • Monitoring-vriendelijkheid: de mate waarin de methode u toelaat om de beschermde omgevingen te monitoren voor SEO-doeleinden.
  • Risico op menselijke fouten: de mate waarin de methode kan leiden tot menselijke fouten, die van invloed zijn op SEO.
Methode Gebruiksvriendelijkheid Toegang voor derden SEO-vriendelijkheid Monitoring-vriendelijkheid Risico op menselijke fouten
HTTP auth no no no no no
VPN no no no no no
Robots directives no no no no no
Robots.txt no no no no no
Canonical links no no no no no
Whitelisten specifieke user-agents no warning no no no

Method 1: HTTP authenticatie - jouw beste optie 🏆

De beste manier om te voorkomen dat gebruikers en zoekmachines toegang krijgen tot uw development- en staging-omgevingen, is via HTTP-authenticatie. Zorg er ondertussen voor dat u het met HTTPS implementeert, omdat u niet wilt dat gebruikersnamen en wachtwoorden als platte tekst over het internet reizen.

We raden aan de IP-adressen op uw kantoor op whitelisten en externe partijen en externe teamleden toegang te bieden via een gebruikersnaam / wachtwoord-combinatie.

Op deze manier hebben zoekmachines geen toegang en je hebt volledige controle over wie wat kan zien. U kunt jouw staging-omgeving voorbereiden met dezelfde robots.txt die je in de productieomgeving zult gebruiken, evenals met de juiste robot directives en canonicals. Hiermee kun je een representatief beeld krijgen van jouw staging-omgeving wanneer je deze monitort op problemen en wijzigingen voorafgaand aan de lancering.

Een ander voordeel hiervan is dat ontwikkelaars zo niet vergeten de juiste robots.txt, robot directives en canonicals in de productieomgeving te publiceren.

Dit is een veel betere benadering dan het gebruik van robots.txt en / of robots noindex-directives en canonical links, omdat deze niet voorkomen dat andere mensen toegang tot deze sites krijgen, en zoekmachines dergelijke richtlijnen niet altijd respecteren.

Bovendien is het bij gebruik van HTTP-authenticatie nog steeds mogelijk om de testtools van Google te gebruiken, zoals AMP, mobielvriendelijkheid en de Structured Data Testing Tool. Creëer gewoon een tunnel.

Hoe stel ik HTTP-authenticatie in?

Hieronder vind je enkele bronnen voor het instellen van HTTP-authenticatie op Apache, nginx en IIS:

Methode 2: VPN access

VPN staat voor “virtual private network.” Je verbindt in principe jouw lokale machine om onderdeel te worden van het bedrijfsnetwerk. En nu dat je deel uitmaakt van het bedrijfsnetwerk, kun je toegang krijgen tot de staging-omgeving. Iedereen die geen deel uitmaakt van het netwerk, heeft er geen toegang toe. Dit betekent dat zowel derden als zoekmachines geen toegang hebben tot de staging-omgeving.

Toegang via een VPN biedt de meeste voordelen van HTTP-authenticatie. Er is echter één groot nadeel: SEO-monitoring oplossingen die niet lokaal worden uitgevoerd, werken mogelijk niet of niet meer. Wanneer je niet in staat zijn de voortgang van je ontwikkelteam te volgen, is lastig en het wordt echt problematisch als je te maken hebt met echt grote websites.

Methode 3: Robots directives

Robots directives worden gebruikt om voorkeuren rond crawlen en indexeren te communiceren. U kunt bijvoorbeeld aan zoekmachines vragen bepaalde pagina’s niet te indexeren en (bepaalde) links niet te volgen.

Je kunt robots-directives instellen in de HTTP-header van een pagina (X-Robots-Tag header), of via de meta-robots-directives in de<head> -sectie. Omdat je behalve pagina’s ook andere inhoudstypen in jouw staging-omgeving hebt, is het aan te raden deX-Robots-Tag header te gebruiken om ervoor te zorgen dat, bijvoorbeeld, PDF-bestanden niet worden geïndexeerd.

Robots directives, zoals de naam al aangeeft, zijn bedoeld voor robots (“crawlers”). Ze voorkomen geen toegang door derden. Ze sturen een gematigd sterk signaal naar zoekmachines om pagina’s niet te indexeren. Ik zeg “gematigd” omdat zoekmachines nog steeds kunnen beslissen om de robots-directives te negeren en jouw pagina’s te indexeren. Het is ook geen monitor-vriendelijke oplossing, omdat net als met robots.txt het kan leiden tot false positives die worden gerapporteerd door SEO-tools.

Bovendien bestaat er een groot risico op menselijke fouten, omdat robots directives uit de staging-omgeving vaak per ongeluk worden meegenomen naar de productieomgeving.

Methode 4: Robots.txt

Het robots.txt bestand geeft de regels voor crawlers weer, dus door robots.txt te gebruiken, kun je zoekmachines vragen om jouw staging-omgeving buiten beschouwing te laten. De meest gebruikelijke manier om dit te doen, is door de volgende inhoud op te nemen in robots.txt:

User-agent: *
Disallow: /

Dit voorkomt dat crawlers van zoekmachines de site crawlen, maar ze kunnen deze nog steeds indexeren als ze er links naar vinden, wat leidt tot lijsten zoals deze:

Google description not available robots.txt

Sommige mensen nemen de niet-officiëleNoindex directive op in hun robots.txt. We raden dit niet aan, omdat het een slechtere manier is om te voorkomen dat uw staging-omgeving toegankelijk is dan het gebruik van eenDisallow directive, omdat het echt een niet-officiële richtlijn is.

Jouw robots.txt biedt geen daadwerkelijke bescherming tegen toegang van derden tot de site en het ontregelt ook SEO-monitoring tools, wat mogelijk tot false positives leidt. Bovendien creëer je een groot risico op menselijke fouten: ook hier wordt de robots.txt uit de staging-omgeving vaak per ongeluk meegenomen naar de productieomgeving.

Methode 5: Canonical links

De canonical link informeert zoekmachines over de canonieke versie van een pagina. Als de staging-omgeving verwijst naar de productieomgeving, moeten alle signalen worden geconsolideerd met de productieomgeving.

Anders lijken canonieke links op robots directives, met name hun nadelen:

  • Ze laten derden nog steeds toegang hebben tot de staging-omgeving.
  • Ze zijn geen monitor-vriendelijke oplossing, omdat ze ertoe kunnen leiden dat false positives door SEO-tools worden gemeld.
  • Er is een risico op menselijke fouten, omdat canonical directives van de staging soms per ongeluk worden meegenomen naar de productieomgeving.

Methode 6: Whitelisten van specifieke user agents

De whitelisting van specifieke user-agents voor toegang tot een staging-omgeving kan worden gebruikt om SEO-specialisten toe te staan een staging-omgeving te monitoren, zolang hun SEO-tools het instellen van aangepaste user-agents ondersteunen. Ze kunnen een verzonnen user-agent maken en die gebruiken, terwijl ze alle andere user-agents (inclusief browsers) blokkeren.

Maar dit is niet een erg gebruiksvriendelijke aanpak, omdat handmatige authenticatie via uw browser moeilijker wordt. Het is ook geen erg veilige aanpak: wanneer derden weten dat je voor of bij bedrijf X werkt en zij zich bewust zijn van jouw user-agent (misschien omdat ze een ontevreden klant zijn), kunnen zij mogelijk toegang krijgen tot de staging-omgeving.

Hoe kom je erachter of jouw staging-omgeving wordt geïndexeerd?

Hier zijn een paar manieren om uit te zoeken of jouw staging-omgeving wordt geïndexeerd. Dit zijn de twee meest voorkomende:

Optie 1: site query

Als je weet dat jouw staging-omgeving wordt uitgevoerd op een subdomein, kun je een site query uitproberen, zoals:site:example.com -inurl:www

Deze query retourneert alle Google-geïndexeerde pagina’s voor het domein example.com, behalve de sites die”www” bevatten.

Hier is een link naar een voorbeeld query

Optie 2: Google Analytics

Als je de URL van jouw staging-omgeving niet weet, kun je proberen deze te checken in Google Analytics:

  • Ga naar Audience > Technology en kies Network.
  • Selecteer Hostname als de Primary Dimension.
  • Zoek naar hostnamen die een ander domein hebben, of subdomeinen zoals staging, test or dev bevatten.

Jouw reeds geïndexeerde staging-omgeving verwijderen uit de index

Oh Oh. Jouw staging-omgeving is al geïndexeerd door zoekmachines, en jij bent degene die het moet repareren. Nou, het goede nieuws is: als je de onderstaande stappen volgt, komt het goed. En ze zijn gemakkelijk.

Stap 1: verberg zoekresultaten

Controleer de staging-omgeving in webmasterhulpprogramma’s zoals Google Search Console en Bing Webmaster Tools en URL-verwijdering (zie de documentatie van Google en de documentatie van Bing). Voor Google wordt dit verzoek vaak binnen enkele uren verleend (Bing duurt iets langer) en dan wordt jouw staging-omgeving niet weergegeven in zoekresultaten. Maar er is een probleem: het staat nog steeds in de indexen van Google en Bing; het wordt gewoon niet getoond. In het geval van Google is de staging-omgeving slechts 90 dagen verborgen. Binnen dit tijdsbestek moet je ervoor zorgen dat je op de juiste manier de verwijdering van uw pagina’s uit de indexen van zoekmachines aanvraagt: via de robots noindex directive.

Stap 2: de noindex directive toepassen en pagina’s opnieuw laten crawlen

Zorg ervoor dat je de robots noindex directive toepast op elke pagina in jouw staging-omgeving. Om het proces van zoekmachines die deze pagina’s herschrijven te versnellen, dien een XML sitemap in. Bekijk nu uw server logs voor de verzoeken van zoekmachines om uw eerder geïndexeerde (en nu ‘niet-geïndexeerde’) pagina’s te controleren, om er zeker van te zijn dat ze het bericht ‘door is gekomen’.

In de meeste gevallen zijn deze 90 dagen voldoende om zoekmachines te laten zien dat ze de pagina’s van de staging-omgeving uit hun index moeten verwijderen. Maar als dat niet zo is, herhaal dan het proces.

Zodra alles is voltooid, beveilig je de staging-omgeving met HTTP-authenticatie om ervoor te zorgen dat dit niet opnieuw gebeurt en verwijder je de XML-sitemap uit de Google Search Console en Bing Webmaster Tools.

Andere nuttige bronnen

Hier zijn enkele andere nuttige bronnen voor het beveiligen van staging-omgevingen:

Blijf leren en lees verder!

Nu dat je hebt geleerd wat de beste manier is om jouw staging-omgeving te beveiligen, blijf leren met deze artikelen:

Probeer 14 dagen gratis

Binnen 20 seconden aan de slag

Gelieve een geldige domeinnaam (www.voorbeeld.nl) op te geven.
  • Geen credit card nodig
  • Geen installatie nodig
  • Geen verplichtingen