De gevolgen voor SEO bij A/B testen

A/B-testen is een fantastische manier voor online marketeers om hun website te optimaliseren voor hun lezers. Soms kan een afbeelding of een stukje tekst net het verschil maken tussen een twijfelende bezoeker en een nieuwe klant.

Zoekmachine optimalisatie (SEO) is een manier om je website zo in te richten dat het voor zoekmachines duidelijk is welke informatie jouw website te bieden heeft en waarom jouw content relevant genoeg is om bovenaan te zetten in de zoekresultaten.

A/B-testen en SEO lijken op het eerste gezicht echter moeilijk met elkaar te verenigen. Met A/B-testen heb je deels dubbele content die vaak wisselt. Dat terwijl zoekmachines werken door een index van informatie op te bouwen. Maar dat gaat nogal moeilijk als je geen vaste content hebt, of een boel dubbele content, één van de grote zondes op SEO-gebied.

Gelukkig wordt de soep nooit zo heet gegeten als die geserveerd wordt. Zolang je de spiders van Google duidelijk maakt welke content ze moeten indexeren, maakt het Google verder weinig uit wat je allemaal op je website doet.

In dit artikel worden vier manieren besproken waarop je kunt zorgen dat je zonder zorgen kunt A/B-testen en hiermee SEO waarde verliest of daling zult zien in je organische verkeer (door bijvoorbeeld een penalty).

Vermijdt cloaking

Een techniek die sommige A/B-testers inzetten is ‘cloaking’. Cloaking, of verbergen, is het tonen van één versie van je website aan de Googlebot user agent, en een andere versie aan je gewone bezoekers.

De gedachte hierachter voor A/B-testen is dat je de spiders van Google uit wilt sluiten van de test door hun de ‘echte’ versie te tonen. Omdat cloaking echter veel misbruikt wordt voor black hat SEO praktijken treedt Google hier heel streng tegen op en kan het zelfs leiden tot uitsluiting van je website in de zoekresultaten.

Zorg er dus voor dat je bezoekers niet over verschillende versies van je A/B-test verdeeld op basis van user agent. Het gaat Google er niet om dat hun bot een versie of een andere krijgt te zien, maar dat de gebruikerservaring van de bot hetzelfde is als die van een willekeurige bezoeker.

Gebruik ‘rel=canonical’

Als je een A/B-test runt met meerdere URLs, dan kan je het ‘rel=canonical’ element toevoegen aan je pagina om aan Google aan te geven welke URL je graag geïndexeerd wilt hebben.

Google raadt aan om het canonical element te gebruiken in plaats van de noindex tag, omdat deze dichter bij je intentie ligt. Je wilt namelijk niet dat bepaalde content niet geïndexeerd wordt, je geeft alleen aan dat er dubbele content is, en welke content origineel is. Zo kan Google deze pagina’s ook als zodanig groeperen en indexeren. Is het technisch nou niet mogelijk om gebruik te maken van een canonical, zorg dan zeker voor een noindex tag in HTML, HTTP Header of robots.txt (liefst allemaal).

Gebruik 302 redirects

De meest-gebruikte manier om een pagina te redirecten is door een 301 te gebruiken. Stel je verplaatst content van één pagina naar een andere pagina, dan wil je de URL van de oude pagina niet helemaal opgeven. Je weet nooit waar er nog links naar die pagina rondzwerven, en het is zonde als nieuwe bezoekers daardoor een 404-melding krijgen. Daarnaast kan er een grote SEO waarde op de link zitten die je niet zomaar weg moet gooien. Met de 301 geef je eigenlijk een verhuisbericht door: je laat de browser, maar ook de spiders van zoekmachines, weten dat de pagina verhuisd is naar een nieuwe URL.

In A/B-testen worden 301 redirects vaak gebruikt om bezoekers van de originele URL te redirecten naar een test-versie. Maar in het geval van een A/B-test gaat het niet om een permanente verhuizing, maar om een tijdelijke verhuizing. Na het afronden van de test wordt de originele URL namelijk gewoon weer in gebruik genomen. Daarvoor is de 302 redirect in het leven geroepen: dat is namelijk een tijdelijke redirect.
Dus als je met een redirect werkt voor A/B testen, let dan op dat je een 302 header gebruikt.

Het belangrijkste voor zoekmachines is dat je duidelijk maakt dat ze jouw originele URL niet helemaal uit hun index moeten gooien, maar dat deze slechts tijdelijk niet gebruikt moet worden. Bij een volgende indexatie door de spiders zullen ze weer checken of de redirect nog van toepassing is, en zo niet, dan wordt de oude URL gewoon weer in ere hersteld.

Als de test klaar is, zorg dan wél voor een 301 redirect. Je wilt namelijk niet dat 2 verschillende URLs met vrijwel identieke informatie van hetzelfde domein in de zoekresultaten staan. Zorg dus dat als je test klaar is dat je een 301 header plaatst op de URL die de test verloren heeft naar de URL die de test gewonnen heeft. Is het in jouw A/B testpakket zo dat de originele URL altijd blijft bestaan en dat daar de testresultaten op verwerkt worden. Zorg dan dat de test URL doorverwijst naar de originele URL.

Dit probleem treed vaak op bij websites waar A/B testen gedaan wordt door eigen code in combinatie met bijvoorbeeld Google Analytics.

Run een test niet langer dan noodzakelijk

De tijd die er nodig is om een betrouwbare test te runnen, daar zijn hele boeken over geschreven. Het is afhankelijk van verschillende factoren, waaronder het aantal bezoekers en het aantal conversies; een goede test tool zal je precies kunnen vertellen wanneer je test significantie heeft bereikt. Bijvoorbeeld de A/B tijdsduur calculator van VWO.

Wanneer je de test hebt afgerond moet je eigenlijk zo snel mogelijk de variaties van de test verwijderen en de website updaten met de winnende content die je wilt gaan gebruiken. Verwijder dus ook de elementen van de test, zoals alternatieve URL’s en testscripts.

Wanneer Google merkt dat een test langer loopt dan eigenlijk normaal te verwachten is, kunnen ze dit interpreteren als een manier om zoekmachines om de tuin te leiden, mogelijk een verkapte manier van cloaking. Dit kan vooral voorkomen wanneer je in je A/B-test een bepaalde variant aan een hele grote groep gebruikers toont.

Testen van content of visuele elementen

Een A/B-test kan gedaan worden in vele vormen. Je kunt verschillende headlines testen, je kunt de toon van je content of de vorm van je call-to-action testen, je kunt verschillende afbeeldingen testen, complete indelingen van pagina’s, etc. Maar een test kan ook simpelweg de locatie van een knop, een tekst of een afbeelding zijn, of de kleur.

Wat je test maakt een groot verschil op de mogelijke impact van je A/B-test op je zoekmachine optimalisatie. De spiders van Google en andere zoekmachines kijken alleen maar naar de inhoud van je pagina. Of een knop links of rechts staat maakt voor Google niet (altijd) uit. De volgorde van elementen in je HTML is wel belangrijk. Ook als je een witte website met zwarte tekst, of een zwarte website hebt met witte tekst; voor de Googlebot is het allemaal hetzelfde. Het gaat Google ook niet om hele gedetailleerde content. Als je een pagina hebt over een online marketing cursus, dan maakt het voor je SEO helemaal niets uit of er op je call-to-action knop “Schrijf nu in!” of “Registreer nu!” staat; dat is namelijk niet de content van de pagina die voor de zoekmachine relevant is.

Vanuit Conversieoptimalisatie is het label op je buttons zeker wel belangrijk. Ook voor je linkprofiel is dit belangrijk omdat Google een divers ankertekstprofiel wil zien. Als jij een website of specifieke pagina hebt en iedereen linkt er altijd met dezelfde ankertekst naartoe dan is dat een signaal dat dat niet een natuurlijke linkprofiel is. Dus voor de specifieke pagina en de SEO waarde daarvan maakt het Google niet uit wat het label van een button of een ankertekst van een link is, maar dit kan wel invloed hebben voor de pagina waar de button of link naartoe linkt.

Uiteraard kan het geen kwaad om een goede hiërarchie op te zetten en om de juiste redirects te gebruiken, maar in situaties waarin de content van een pagina inhoudelijk feitelijk gelijk blijft, is er eigenlijk geen impact van je A/B-test op je SEO.

Reacties (4)

  1. Hi Mike,

    Dank voor het artikel / het delen van je inzichten.

    In de praktijk werken de meeste bedrijven met software zoals Optimizely en VWO voor hun A/B-testen of gebruiken ze hun Tag Management oplossing om de testvariaties te injecteren op hun webpagina. Dit is allemaal hetzelfde principe: je neemt een .js library op op je website en als je browser javascript begrijpt en je zit op een URL waarop een test plaats vindt (en je zit in de testgroep en een testvariant), dan wordt de (vaak jQuery) code uitgevoerd.

    De bot van Google probeert wel steeds vaker javascript uit te voeren (zie: http://googlewebmastercentral.blogspot.nl/2014/05/understanding-web-pages-better.html), maar zover ik weet voeren ze de code achter A/B-testen nog niet uit. Nadeel: dat zal niemand echt willen bevestigen of ontkennen. Ik ga er nu nog steeds van uit dat de bot de default (control) ziet. Voor ons de reden om ook altijd te testen tegen een kopie control en niet de control zelf. In die control kan publiek zitten dat nooit naar een variant wordt gestuurd (en is dus geen zuivere populatie – los van de discussie of dit meetbare bezoekers zijn).

    Je lijkt dus prima een headline A/B-test te kunnen uitvoeren wanneer je dit via een javascript oplossing in page doet – zolang je dit maar als test doet en niet voor 100% van je bezoek is het geen cloacking (let dus op als winnaars live zetten lang duurt via de normale IT route en je je A/B-test tool misbruikt om winnaars 100% live te zetten…).

    Interessante discussie die je bij mij aangezwengeld is echter: leuk dat de A/B-test uitwijst dat een bepaalde headline tot een hoger conversie percentage leidt, maar zodra je deze echt live zet en de bots ‘m meepakken kan zomaar je traffic halveren omdat de tekst SEO copywriting wise slecht is. Dus: zoals altijd: pas op wat je test en weet wat je doet. Met A/B-testen kun je onwijs groeien, maar ook de plank mis slaan als je het niet goed aanpakt 🙂

    disclaimer: ik ben consultant / mijn bedrijf verkoopt diensten die A/B-testen makkelijk maken / goed uitvoeren.

    • @Ton: Javascript implementatie van een testtool zou er in moeten staan, zou zweren dat ik daar iets over had verteld. Blijkbaar niet. Wat je zegt klopt. Op deze manier zijn veel van de bovenstaande zaken niet meteen een probleem. Met Google Experiments bestaan de problemen wel.

      De interpretatie van Javascript door bots is wel degelijk zo ver dat een bot in een test terecht kan komen. Springest heeft er ook al over geblogd: http://devblog.springest.com/ab-testing-seo-google/
      DOM manipulatie is prima te doen (het header voorbeeld dat je geeft) met Optimizely.
      Grootste probleem zit hem er in als je met meerdere URL’s gaat werken.

      Het meest interessante (volgens mij zijn er ook nog maar weinig cases van) is je laatste opmerking. Dus uit een test blijkt dat iets beter converteert, maar zodra je dat live zet zak je in je rankings. Ik denk dat dat in de praktijk wel meevalt (moet zeggen dat ik het ook nog niet gezien heb), daarnaast optimaliseer je vaak conversiepagina’s die qua zoekmachinevindbaarheid minder belangrijk zijn of zelfs op noindex staan.

  2. Leuk artikel. Kleine opmerking hierover:

    “Is het technisch nou niet mogelijk om gebruik te maken van een canonical, zorg dan zeker voor een noindex tag in HTML, HTTP Header of robots.txt (liefst allemaal).”

    Strikt gezien is een disallow regel (ik neem aan dat je daar op doelt) in robots.txt niet bedoeld om content niet te laten indexeren. Je geeft hiermee alleen aan dat je niet wil dat een crawler bepaalde inhoud van je site gaat bezoeken. Dat kan echter niet altijd voorkomen dat een pagina niet in de index verschijnt.

    Eén noindex-methode zal volstaan in dit geval; of dat nu middels een noindex tag is of via een HTTP Header.

Reacties zijn gesloten.