Soms zie je in de zoekresultaten ineens een melding die je hartslag omhoog jaagt. Deze week ging er zo’n geval rond: iemand zag in Google een bericht dat zijn website “offline” zou zijn sinds begin 2026. De reflex was snel: het zal wel Google’s AI zijn. John Mueller van Google keek mee en wees op iets wat ik in de praktijk vaker zie gebeuren: een onschuldige JavaScript keuze die voor bots en sommige gebruikers een heel ander verhaal laat zien dan jij bedoelt.
Een klacht op Reddit, maar vooral een link naar een blog
De persoon in kwestie plaatste op Reddit geen uitgebreide uitleg, maar linkte vooral naar een eigen blogpost waarin Google en “AI” de schuld kregen van de offline melding in de SERPs. Dat gaf Mueller een voordeel: hij hoefde niet te gissen naar wat er bedoeld werd, hij kon direct naar de site gaan en zien wat er technisch gebeurde.
En dat is meteen de eerste les. Als je een probleem wilt begrijpen, kijk dan eerst naar wat er echt wordt uitgeserveerd aan de buitenwereld. Niet naar wat je browser laat zien nadat alles geladen is.
Hoe een ingewikkelde titel de echte oorzaak verbergt
De blogpost had een titel die klinkt alsof hij uit een onderzoeksrapport komt: “Google Might Think Your Website Is Down: How Cross page AI aggregation can introduce new liability vectors.”
Die termen, zoals “cross page AI aggregation” en “liability vectors”, zijn geen gangbare begrippen in computer science. Het leest indrukwekkend, maar het helpt je niet dichter bij de oorzaak.
Met “cross page” doelde de schrijver waarschijnlijk op wat Google Query Fan Out noemt. In Google’s AI Mode kan een vraag worden opgesplitst in meerdere zoekopdrachten, die vervolgens via de klassieke zoekmachine informatie ophalen. Dat is op zich een nuttig concept om te begrijpen, maar het verklaart nog niet waarom Google denkt dat een site niet beschikbaar is.
En “liability vector” klinkt technisch, maar in SEO en NLP is “vector” een echt begrip, alleen niet op deze manier. Het leidt af, terwijl je juist helderheid nodig hebt.
De schrijver wist zelf ook niet hoe Google dit bepaalt
Wat me opviel is dat de auteur in de tekst eerlijk toegeeft dat hij niet weet of Google überhaupt kan zien of een site up of down is. Hij schrijft ongeveer: ik ben me niet bewust van een speciale mogelijkheid van Google om te detecteren of websites bereikbaar zijn, en zelfs als mijn interne service down zou zijn, kan Google dat niet zien want het zit achter een login.
Daar zit een belangrijk punt in. Google kan inderdaad niet “achter je login kijken” zoals een ingelogde gebruiker dat kan. Google baseert zich op wat het kan crawlen en renderen. Als jouw publiek vooral ingelogd is, moet je extra scherp zijn op wat er aan de buitenkant zichtbaar is.
De auteur leek daarnaast verrast dat Google relatief verse informatie gebruikte. Hij redeneert dat de melding “sinds begin 2026” erop wijst dat Google recente data moet hebben, terwijl de site pas halverwege 2025 bestond. Hij zet dat af tegen parametric knowledge, dus kennis die in het taalmodel zit vanuit training. Dat klinkt logisch, maar voor dit soort meldingen is het vaak simpeler: Google leest gewoon tekst die het op je pagina tegenkomt, of dat nu bedoeld is als tijdelijke placeholder of niet.
Schieten met hagel werkt zelden, ook niet bij SEO
Omdat de schrijver niet wist waar het vandaan kwam, paste hij een “shot in the dark” toe. Hij verwijderde een pop up, in de hoop dat dát het probleem was.
Ik begrijp die neiging. Als je omzet draait uit organisch verkeer en er staat ineens “offline” bij je merknaam, wil je iets doen. Alleen, als je begint te veranderen zonder te weten wat je oplost, kun je later niet meer terughalen wat het echte probleem was. Je bouwt ruis in je diagnose.
Daarbovenop uitte hij een bredere angst: dat Google’s AI willekeurige stukjes tekst van je site kan pakken en die als antwoord kan presenteren, ook bij vragen die er weinig mee te maken hebben. Dat gevoel is herkenbaar, zeker nu AI antwoorden zichtbaarder zijn. Alleen is de basis nog steeds dezelfde: AI zoekt eerst via de klassieke index, en vat daarna samen wat het gevonden heeft.
Wat er echt gebeurde volgens John Mueller
Mueller reageerde rustig en precies. Hij vroeg eerst of het om de site van de schrijver ging en gaf daarna een heel concrete aanbeveling: gebruik geen JavaScript om tekst op je pagina te veranderen van “not available” naar “available”. Laad in plaats daarvan dat hele blok pas via JavaScript, zodat iemand die je JavaScript niet uitvoert ook niet eerst die misleidende tekst te zien krijgt.
Hij maakte de vergelijking met een bekende Google waarschuwing. Verander niet via JavaScript een robots meta tag van “noindex” naar iets wat indexering zou toestaan. Google ziet namelijk niet altijd wat jij pas later met scripts ombouwt.
De kern is dit: de pagina serveerde eerst in de basis HTML een placeholder, bijvoorbeeld “niet beschikbaar”. Vervolgens verving een script die tekst na het laden door de echte status. Voor normale bezoekers lijkt dat prima te werken, want hun browser voert de JavaScript uit.
Maar Google en andere clients kunnen soms de eerste versie oppakken. Dan indexeren ze dus die placeholder tekst, en niet jouw uiteindelijke bedoeling. Als daar staat dat iets niet beschikbaar is, of dat een dienst offline is, dan kan dat in zoekresultaten terugkomen als feitelijke informatie over je site.
Mueller’s alternatief is ouderwets, maar betrouwbaar: zorg dat de juiste informatie vanaf het begin in de HTML staat, of zorg dat de content die afhankelijk is van JavaScript helemaal niet als verkeerde tekst start. Dan krijgen gebruikers en zoekmachines hetzelfde verhaal.
Wat jij hiermee moet, als je een groeiend bedrijf runt
Als ondernemer of marketeer wil je geen tijd verliezen aan discussies met Google, je wilt dat je site klopt. Dit soort issues zitten vaak niet in “AI”, maar in hoe je frontend is gebouwd.
In de praktijk helpt het om op drie plekken te kijken, zonder meteen overal aan te draaien. Begin met de broncode, dus wat er echt in de HTML staat voordat scripts draaien. Als daar tekst staat die je alleen als tijdelijke vulling bedoelt, wees dan extra voorzichtig.
Kijk daarna in Google Search Console bij de URL inspectie, en gebruik waar mogelijk de optie om te testen hoe Google de pagina ziet. Als Google een andere versie ziet dan jij, weet je genoeg.
Tot slot, bespreek met je developer of bureau of belangrijke statusinformatie, beschikbaarheid, prijzen, voorraad en contactmogelijkheden in de eerste HTML moet staan. Zeker bij e commerce en leadgeneratie kan één verkeerd zinnetje in een placeholder je conversie en vertrouwen kosten.
Ik zeg dit een beetje als een bezorgde ouder: je hoeft niet slimmer te klinken dan het probleem. Je moet het probleem zien zoals het is, en daarna pas bouwen aan de oplossing.
De grotere les achter dit hele verhaal
De echte schade in dit soort situaties komt vaak niet door Google, maar door aannames. Als je niet weet hoe AI zoekresultaten zijn opgebouwd, ga je snel denken dat er van alles willekeurig gebeurt. Dan wordt een technisch detail ineens een groot verhaal over “cross page aggregatie” en “liability vectors”, terwijl de oorzaak simpel is.
AI in search is grotendeels een laag bovenop de klassieke zoekmachine. Het vat samen wat het vindt. Dat betekent dat jouw basiscontent, en hoe die wordt uitgeserveerd aan bots, nog belangrijker wordt.
Dus als je morgen iets raars ziet in de SERPs, pak het volwassen aan. Stop even met gokken, verzamel bewijs, kijk naar wat Google echt kan lezen, en fix daarna gericht. Dat bespaart tijd, frustratie en vaak ook geld.