SEO-regressie voorkomen: zorg dat een deploy je vindbaarheid niet stilletjes sloopt

SEO-regressie betekent dat je vindbaarheid achteruitgaat door een wijziging die je zelf hebt doorgevoerd, vaak zonder dat dat de bedoeling was. Het verschilt van een Google-update of een actie van een concurrent: de oorzaak ligt binnen je eigen site, in een deploy, een plugin-update, een themawissel of een aanpassing in het CMS. Juist omdat de oorzaak intern is, is de regressie meestal goed te voorkomen, mits je hem op tijd opmerkt.

Het venijnige zit in de vertraging. Als je per ongeluk een noindex aanzet, valt de pagina niet meteen uit Google. Eerst moet de crawler langskomen, dan moet Google de instructie verwerken, en pas daarna verdwijnt de pagina uit de index. Dat kan dagen tot weken duren. In die periode lijkt alles nog normaal, terwijl de schade al onderweg is. Tegen de tijd dat je verkeer zichtbaar inzakt, ben je vaak al twee of drie weken verder en is het lastig terughalen waar het misging.

Daar komt bij dat de meeste mkb-sites geen vaste SEO-controle hebben na een wijziging. Een nieuwe knop wordt visueel gecontroleerd, een formulier wordt getest, maar of de title nog klopt en of de canonical nog naar de juiste URL wijst, kijkt vrijwel niemand na. Die blinde vlek is precies de plek waar regressie ongezien ontstaat en blijft zitten.

Een handvol technische instellingen veroorzaakt het leeuwendeel van alle stille SEO-schade. De grootste is de noindex: een metatag of HTTP-header die Google vertelt een pagina niet op te nemen in de zoekresultaten. Veel CMS-systemen en stagingomgevingen zetten standaard een sitebrede noindex aan zodat een testversie niet in Google komt. Gaat de site live zonder dat dit vinkje weer uit gaat, dan verdwijnt je complete website uit de index. Dit is een van de meest voorkomende en meest pijnlijke fouten die we tegenkomen.

Daarnaast zijn er de inhoudelijke signalen die kapot kunnen gaan bij een templatewissel. Een title-tag die verdwijnt of overal hetzelfde wordt, een meta description die wegvalt, of een H1 die per ongeluk uit de nieuwe layout is geknipt. Google gebruikt deze elementen om te begrijpen waar een pagina over gaat en hoe hij in de zoekresultaten wordt getoond. Verdwijnt de H1 of staat er op elke pagina dezelfde title, dan verliest Google houvast en zakken je posities geleidelijk weg.

Tot slot de verwijzende instructies: de canonical-tag, robots.txt en de sitemap. Een verkeerde canonical die naar de homepage of naar een verkeerde URL wijst, vertelt Google dat je echte pagina een duplicaat is en niet zelfstandig hoeft te ranken. Een robots.txt met een regel als Disallow: / blokkeert je hele site voor crawlers. En een sitemap die na een migratie verwijst naar oude of niet-bestaande URL's, stuurt Google rond in een doolhof. Stuk voor stuk kleine bestanden, met grote gevolgen.

In de praktijk ontstaat regressie bijna altijd op een moment dat niemand met SEO bezig is. Een voorbeeld: een bureau bouwt een nieuwe productpagina-template, test die op een stagingomgeving met een sitebrede noindex, en zet de template live. De noindex reist mee naar productie omdat de instelling in het thema zat en niet in de omgeving. Resultaat: alle productpagina's vallen binnen drie weken uit Google, terwijl de website er perfect uitziet.

Een ander veelvoorkomend scenario is de plugin- of CMS-update. Een SEO-plugin krijgt een update die een instelling reset, of een nieuwe versie van het CMS verandert hoe canonicals worden gegenereerd. Niemand heeft een regel code aangeraakt, en toch wijzen ineens alle canonicals naar de verkeerde pagina. Omdat de update vanzelf draaide, is er ook geen duidelijk moment waarop iemand denkt: laat ik de SEO even nakijken.

Migraties zijn de derde grote bron. Bij een overstap naar een nieuw platform, een nieuwe domeinnaam of een nieuwe URL-structuur gaat er veel goed, maar verdwijnt soms de robots.txt, raakt de sitemap verouderd of vervallen redirects van oude naar nieuwe URL's. De site werkt voor bezoekers, maar Google ziet honderden kapotte signalen tegelijk. Dit is het type schade dat maanden nawerkt als je het niet snel corrigeert.

De klassieke manier om regressie te ontdekken is achteraf: je ziet in Google Search Console of in je statistieken dat het organische verkeer wegzakt. Het probleem is dat dit een achterlopend signaal is. Verkeer reageert pas nadat Google je wijziging heeft verwerkt, dus op het moment dat de grafiek daalt, ben je vaak al weken te laat en is de oorzaak moeilijk te herleiden tussen alle wijzigingen die je sindsdien hebt gedaan.

De betere aanpak is om de oorzaak te bewaken in plaats van het gevolg. Niet wachten tot het verkeer daalt, maar direct na elke wijziging controleren of de SEO-fundamenten nog overeind staan: staat de noindex nog uit, zijn de titles en descriptions er nog, klopt de canonical, is de robots.txt ongewijzigd, leeft de sitemap nog, en staat de H1 op zijn plek. Doe je dit door telkens twee momentopnames te vergelijken, dan zie je een verslechtering meteen, ongeacht hoeveel weken Google er nog over doet om hem te verwerken.

Dit vergelijken is precies waar CheckBorg op inzet. CheckBorg scant je site periodiek en heeft regressie-bewaking ingebouwd: zodra de SEO sinds de vorige scan verslechtert, bijvoorbeeld een nieuw verschenen noindex, een verdwenen title of een canonical die ineens ergens anders heen wijst, krijg je een alert. Zo merk je de wijziging op het moment dat hij gebeurt, niet pas als je posities al zijn gekelderd. Het verschuift je van reageren op schade naar voorkomen ervan.

Voorkomen begint met het inbouwen van een vast controlemoment rond elke wijziging die live gaat. Spreek met je team of bureau af dat een deploy, een themawissel of een grote update pas afgerond is als de SEO-fundamenten zijn nagekeken. Dat hoeft geen halfuur werk te zijn: een korte vergelijking van de belangrijkste signalen voor en na de wijziging vangt het overgrote deel van de problemen af. De truc is dat het standaard gebeurt, niet alleen als iemand er toevallig aan denkt.

Maak daarnaast onderscheid tussen je stagingomgeving en productie. Houd de noindex bewust aan op staging en zorg dat er een expliciete stap is die hem op productie weer uitzet, met een controle erop. Veel ongelukken ontstaan doordat instellingen ongemerkt meereizen van test naar live. Door dat reizen zichtbaar te maken in je proces, haal je de grootste risicobron weg.

Tot slot helpt continue bewaking om de menselijke factor op te vangen. Mensen vergeten, plugins updaten zichzelf, en niet elke wijziging gaat via een net proces. Een onafhankelijke scanner die los van je eigen team meekijkt en alarm slaat bij een verslechtering, vormt het vangnet onder je afspraken. CheckBorg draait die controle automatisch, zodat je niet afhankelijk bent van of iemand er die week aan dacht. De combinatie van een vaste menselijke controlestap en geautomatiseerde regressie-bewaking is wat een tijdelijke dip voorkomt die anders maanden had nagewerkt.