Bah

NLS extensies /plugins blokken voor Concrete CMS met metadata, structured data, AI samenvattingen, canonicals, sitemaps en betere vindbaarheid en vormgeving.

Versio en Neostrada beveiligen tot zoekmachines en AI er niet meer bij kunnen

Waarom dit voor mij belangrijk is

CloudLinux heeft mijn websites gecontroleerd

WebShield onderschept crawlers voordat ze mijn website bereiken

De sitemap wordt geblokkeerd

CloudLinux zegt dat de provider dit moet oplossen

Er bleek nog een probleem te zijn

Volgens CloudLinux komt die blokkade niet van Imunify360

ClaudeBot kan zelfs robots.txt niet lezen

Dit is geen klein SEO-probleem meer

Daarom bouw ik controles in

Mijn software doet wat ik ervan verwacht

Dit gaat niet alleen over mijn eigen website

Daarom moet je SEO-systeem hier rekening mee houden

Wat CloudLinux nu van Versio en Neostrada vraagt

Mijn conclusie

Versio en Neostrada beveiligen tot zoekmachines en AI er niet meer bij kunnen Mijn website doet precies wat hij moet doen. Mijn SEO-software zorgt ervoor dat de inhoud van mijn website snel, duidelijk en bruikbaar beschikbaar is voor zoekmachines en AI-systemen. Sitemaps zijn beschikbaar, robots.txt is beschikbaar, llms.txt is beschikbaar en mijn snelle publieke pagina’s staan klaar. Zodra een crawler mijn website daadwerkelijk bereikt, werkt dat ook gewoon. Daar zit het probleem. Vóór mijn website staat de beveiliging van de hostingprovider. Die beveiliging houdt zoekmachines en AI-crawlers tegen voordat mijn eigen software één regel code uitvoert. Als de hostinglaag de deur dichtgooit, bereikt die crawler mijn website niet. CloudLinux, de maker van Imunify360, heeft dit onderzocht. Waarom dit voor mij belangrijk is Ik bouw software waarmee websites beter gevonden, gelezen en begrepen worden door zoekmachines en AI-systemen. De inhoud van je website moet duidelijk, snel en betrouwbaar overkomen bij systemen die haar indexeren, analyseren of als bron gebruiken. Een zoekmachine of AI-systeem moet niet hoeven raden waar je website over gaat. Daar heb ik mijn software op ingericht. Zodra een crawler mijn website bereikt, gebeurt dat ook. Het probleem ontstaat eerder in de route, bij de hostingprovider. CloudLinux heeft mijn websites gecontroleerd Op 20 augustus 2026 kreeg ik van CloudLinux Support antwoord op een supportticket. Geen standaardverhaal met: “Leeg uw browsercache en probeer het opnieuw.” Ik kreeg een technische analyse die letterlijk bedoeld was om door te sturen naar Neostrada en Versio. CloudLinux onderzocht twee websites op dezelfde infrastructuur: concretecms.nielstieland.com en heelbeter.nl. Beide websites zijn van mij. Beide websites zijn van buiten getest met verschillende echte crawlerprofielen, via IPv4 en IPv6. Hun conclusie was duidelijk. Wanneer een crawler mijn website daadwerkelijk bereikt, werkt mijn snelle crawlerafhandeling en krijgt die crawler de inhoud die beschikbaar hoort te zijn. CloudLinux vond daarna twee problemen buiten mijn eigen applicatie. WebShield onderschept crawlers voordat ze mijn website bereiken De pagina “Please wait while your request is being verified” komt volgens CloudLinux van WebShield. WebShield is onderdeel van Imunify360 en staat vóór mijn eigen website. Wanneer WebShield een crawler tegenhoudt, krijgt mijn website geen kans om te reageren. Mijn SEO-software komt niet aan bod. De snelle publieke pagina’s worden niet geleverd. De crawler ziet de inhoud die voor hem klaarstaat niet. CloudLinux stelde vast dat dit gedrag onder andere afhankelijk is van de reputatie van het IP-adres waar de crawler vandaan komt. Dezelfde crawler komt vanaf het ene IP-adres gewoon binnen en loopt vanaf een ander IP-adres tegen een verificatiepagina aan. Bij bepaalde AI-crawlers verschijnt zelfs een andere HTTP-fout. Voor SEO en AI-vindbaarheid is onvoorspelbare bereikbaarheid precies wat je niet wilt. De sitemap wordt geblokkeerd Een sitemap heeft één functie: zoekmachines vertellen welke openbare pagina’s op een website bestaan. Het is ongeveer het minst geheime bestand dat je op een website kunt hebben. Mijn website maakt die sitemap gewoon. De inhoud bestaat, de URL bestaat en je kunt hem in je browser openen. Toch constateert mijn eigen SEO-diagnose dat een geautomatiseerde bezoeker op diezelfde sitemaproute een Imunify360- of WebShield-verificatie krijgt. Met HTTP 200 nota bene. Daarom kijkt mijn SEO-software niet alleen naar de statuscode. Een server kan 200 OK teruggeven terwijl de zoekmachine helemaal geen sitemap heeft ontvangen. Mijn software controleert ook of op die plek werkelijk de informatie staat die daar hoort te staan. Als website-eigenaar wil je weten of zoekmachines de juiste informatie daadwerkelijk krijgen. Alleen een groen vinkje omdat de server HTTP 200 terugstuurt zegt te weinig. CloudLinux zegt dat de provider dit moet oplossen CloudLinux schrijft aan Neostrada en Versio dat Imunify360 door de hostingprovider wordt beheerd. Ik beschik als shared-hostingklant niet over de instellingen die nodig zijn om dit zelf op te lossen. De maker van het beveiligingsproduct beschrijft meerdere manieren waarop de provider legitieme crawlers correct toelaat. Daarbij wordt onderscheid gemaakt tussen echte crawlers en partijen die zich alleen als crawler voordoen. Ook kunnen betreffende domeinen gericht worden uitgezonderd van de Anti-Bot Challenge. Die mogelijkheden liggen bij Versio en Neostrada, niet bij mij. Er bleek nog een probleem te zijn Tijdens hetzelfde onderzoek ontdekte CloudLinux dat een aantal crawlers structureel HTTP 403 kreeg. Dat gebeurde onder andere bij ClaudeBot, Amazonbot, Bytespider, AhrefsBot, SemrushBot en MJ12bot. Dit speelde op beide onderzochte websites, via IPv4 en IPv6. Ook belangrijke openbare bestanden zoals robots.txt, llms.txt en sitemap.xml werden geraakt. Dat is iets anders dan een crawler tijdelijk afremmen. Deze systemen komen structureel niet binnen terwijl de inhoud gewoon beschikbaar is. Volgens CloudLinux komt die blokkade niet van Imunify360 CloudLinux stelt dat deze HTTP 403 niet afkomstig is van hun eigen Anti-Bot Challenge. Volgens hun analyse lijkt de response door Apache zelf te worden gegenereerd. Hun vermoeden is dat hoger in de hostingomgeving een algemene botblokkade of User-Agent-denylist actief is. Daarom heeft CloudLinux Versio en Neostrada expliciet gevraagd om hun Apache-configuratie en andere beveiligingsregels te controleren. Er spelen dus twee afzonderlijke blokkades: WebShield en daarnaast een blokkade in de serverconfiguratie. ClaudeBot kan zelfs robots.txt niet lezen robots.txt is bedoeld om een crawler te vertellen wat hij wel en niet mag doen. Wanneer een crawler op robots.txt een harde 403 krijgt, kan hij die instructies niet lezen. De blokkade vindt dus plaats voordat hij kan zien hoe ik wil dat hij zich gedraagt. Dat is hetzelfde als iemand de toegang tot het verkeersreglement weigeren en hem daarna verwijten dat hij de verkeersregels niet kent. Dit is geen klein SEO-probleem meer Tien jaar geleden kon je nog zeggen: “Ach, weer een bot minder.” Zo werkt internet niet meer. Zoekmachines gebruiken crawlers. AI-zoekdiensten gebruiken crawlers. AI-assistenten gebruiken zoekindexen en crawlers om actuele informatie te vinden. Een moderne website wordt niet alleen door menselijke bezoekers gelezen. Machines moeten begrijpen welke pagina’s bestaan, welke inhoud daarbij hoort, welke talen beschikbaar zijn en welke informatie actueel is. Daar heb ik mijn SEO-software voor gebouwd. Daarom bouw ik controles in Ik wil niet aannemen dat iets werkt. Ik wil het kunnen zien. Mijn SEO-software controleert of belangrijke informatie werkelijk bereikbaar is. Ze herkent wanneer een crawler een beveiligingspagina krijgt in plaats van de bedoelde inhoud en controleert verschillende openbare routes. Zo wordt zichtbaar of het probleem in mijn website zit of ergens daarbuiten wordt veroorzaakt. Zonder zo’n controle denk je als website-eigenaar maanden dat alles goed gaat terwijl belangrijke crawlers niet binnenkomen. Mijn software doet wat ik ervan verwacht De inhoud staat klaar, belangrijke informatie wordt snel aangeboden en zoekmachines en AI-systemen krijgen bruikbare routes om die informatie te vinden. Mijn software controleert bovendien of een crawler daadwerkelijk de juiste inhoud heeft ontvangen en waarschuwt wanneer een providerchallenge of externe blokkade wordt gevonden. Dat maakt het verschil zichtbaar tussen een website die niet werkt en een website die prima werkt maar onderweg wordt afgeschermd. Wanneer de hostinglaag een bezoeker stopt voordat mijn software aan de beurt komt, kan ik die blokkade vanuit mijn website niet opheffen. Dit gaat niet alleen over mijn eigen website Ik bouw deze software ook voor andere websites. Waar toekomstige gebruikers hun website hosten, weet ik niet. Bij Versio, bij Neostrada, bij een andere shared hoster, op een VPS, op een eigen server of ergens in een bezemkast naast de stofzuiger. Dat hoef ik ook niet te weten. Een sitemap hoort openbaar te zijn, robots.txt hoort leesbaar te zijn en de inhoud van openbare pagina’s hoort bereikbaar te zijn voor crawlers die jij zelf wilt toelaten. Mijn software moet haar werk kunnen doen zonder afhankelijk te zijn van de grillen van een specifieke hostingomgeving. Daarom moet je SEO-systeem hier rekening mee houden Goede SEO-software moet meer doen dan informatie voor crawlers genereren. Ze moet ook controleren of die informatie werkelijk de buitenwereld bereikt. Je website kan technisch uitstekend in orde zijn. Je SEO kan alles netjes hebben opgebouwd. Alle crawlerinformatie kan klaarstaan. Toch kan de infrastructuur erboven ervoor zorgen dat zoekmachines en AI-systemen minder goed bij je inhoud komen. Gaat dat mis, dan wil ik weten waar: website, hosting, beveiligingslaag, crawler of externe provider. Dat vind ik nuttiger dan alleen een groen lampje met: “Uw sitemap bestaat.” Ik wil weten of de crawler hem ook daadwerkelijk gekregen heeft. Wat CloudLinux nu van Versio en Neostrada vraagt CloudLinux heeft Versio en Neostrada gevraagd om hun WebShield-configuratie en crawlerinstellingen te controleren. Ze willen weten waarom bepaalde bron-IP’s worden tegengehouden en vragen om loggegevens waarmee vastgesteld wordt waarom een crawler een challenge krijgt. Daarnaast moet worden onderzocht waarom sommige crawlers structureel met HTTP 403 worden geweigerd. CloudLinux geeft expliciet aan dat dit tweede probleem niet door Imunify360 zelf lijkt te worden veroorzaakt. Versio en Neostrada moeten dus zowel naar WebShield als naar de eigen serverconfiguratie kijken. Dat is geen onredelijk verzoek wanneer de maker van het gebruikte beveiligingsproduct aangeeft waar gezocht moet worden. Mijn conclusie Mijn website maakt de inhoud beschikbaar die zoekmachines en AI-systemen moeten kunnen vinden. Mijn snelle publieke pagina’s werken zodra crawlers de website daadwerkelijk bereiken. Sitemap, robots.txt, llms.txt en de machineleesbare informatie staan klaar. Mijn SEO-software doet precies waarvoor ik haar gebouwd heb en toont aan wanneer die informatie onderweg wordt vervangen of geblokkeerd. Legitieme crawlers worden vóór mijn eigen software onderschept door WebShield of daarna alsnog door een serverregel met HTTP 403 geweigerd. Op dat moment ligt het probleem bij de infrastructuur die bepaalt wie mijn openbare website daadwerkelijk mag bereiken. Versio en Neostrada geven aan last te hebben van AI-bots omdat die veel dataverkeer veroorzaken. Dat probleem begrijp ik. Alleen hoeft de oplossing niet te zijn dat legitieme crawlers simpelweg worden buitengesloten. Echte crawlers kunnen worden onderscheiden van neppe crawlers. Verkeer kan gecontroleerd worden afgeremd. Duidelijke limieten voorkomen dat één crawler alles opslokt. Bij overschrijding kun je een crawler vertellen wanneer hij later terug moet komen. Dat is netter dan de deur dichtgooien voor systemen waarvan ik juist wil dat ze mijn inhoud kunnen lezen. Beveilig mijn website tegen aanvallen. Graag zelfs. Maar beveilig hem niet tegen gevonden worden. Een website die niemand kan hacken is mooi. Wanneer zoekmachines en AI-systemen hem niet betrouwbaar kunnen bereiken, blijft er vooral een goed beveiligde verzameling bestanden over.