Een klant belde me gisteren. Zijn cookiebanner was verdwenen. Niet half zichtbaar, niet verkleurd — gewoon weg. Hij had een dag eerder plugins bijgewerkt en dacht dat dat wel los zou lopen. Dat liep het niet. Ondertussen draaide zijn site zonder toestemmingsbeheer, wat juridisch gezien een probleem is. Dit soort situaties kom ik elke paar weken tegen. Daarom leg ik hier uit hoe je cookiebanner-problemen na een update snel opspoort en oplost.
Waarom cookiebanners juist na updates sneuvelen
Cookieplugins zijn gevoelig. Ze haken in op je thema, op andere plugins en soms op de manier waarop WordPress scripts laadt. Zodra je een van die onderdelen bijwerkt, kan de volgorde van laden veranderen of een functie verdwijnen die de cookieplugin verwachtte.
De meest voorkomende oorzaken zijn:
- Een conflicterende plugin-update — een caching-plugin of een script-optimizer die de cookiebanner wegoptimaliseert of te vroeg laadt
- Een thema-update die een hook heeft verwijderd of hernoemd
- De cookieplugin zelf is bijgewerkt en heeft een instelling gereset of een API-aanroep gewijzigd
- PHP-versie-incompatibiliteit — de hoster heeft ondertussen PHP bijgewerkt en de plugin loopt tegen een deprecated functie aan
Het eerste wat je doet na zo’n melding is de browserconsole openen. Druk op F12, ga naar het tabblad Console en laad de pagina opnieuw. Zie je een JavaScript-fout die verwijst naar de naam van je cookieplugin? Dan weet je al waar je moet zoeken.
Daarna kijk je in het tabblad Netwerk of de cookiescript-bestanden überhaupt worden geladen. Filteren op de naam van je plugin helpt. Als de bestanden een 404 teruggeven, is er iets mis met de plugin-installatie zelf. Dan deactiveer je de plugin, verwijder je hem en installeer je hem opnieuw via de WordPress-repository.
Staat er niets in de console en laden de bestanden gewoon? Dan is het waarschijnlijk een conflict met een caching-plugin. Leeg je cache volledig — ook de server-side cache als je die hebt — en test opnieuw in een incognitovenster. Incognito is belangrijk, want je eigen browser onthoudt al dat je toestemming hebt gegeven.
Cookiewetgeving: wat je site minimaal moet doen
Dit is niet alleen een technisch probleem. Als je cookiebanner het niet doet, draai je zonder rechtsgeldig toestemmingssysteem. De AVG verplicht je om bezoekers actief toestemming te vragen voor niet-noodzakelijke cookies, en die toestemming moet je ook kunnen aantonen.
Wat dat in de praktijk betekent:
- Tracking-cookies (Google Analytics, Facebook Pixel, Hotjar) mogen pas worden geplaatst na expliciete toestemming
- Een pre-aangevinkt vinkje telt niet als toestemming
- Bezoekers moeten net zo makkelijk kunnen weigeren als accepteren
- Je moet bijhouden wanneer iemand toestemming heeft gegeven en waarvoor
De informatie van de Rijksoverheid over de AVG maakt duidelijk dat dit niet vrijblijvend is. De Autoriteit Persoonsgegevens handhaaft actief en heeft al boetes opgelegd aan organisaties die dit niet op orde hadden.
Voor mkb-sites betekent dit concreet: zorg dat je cookieplugin een toestemmingslog bijhoudt. Plugins als Complianz of CookieYes doen dat standaard. Controleer na elke update of die log nog werkt door zelf een test-toestemming te geven en te kijken of die verschijnt in het plugin-dashboard.
Een ander punt: sommige thema’s laden Google Fonts via een externe aanroep naar Google-servers. Dat is een cookie-gerelateerd probleem, want het stuurt het IP-adres van de bezoeker naar Google zonder toestemming. De oplossing is Google Fonts lokaal laden. Dat doe je door de fontbestanden te downloaden en via je thema of een plugin lokaal te serveren. Dat lost tegelijk een klein laadtijdprobleem op.
Testen, loggen en voorkomen dat het weer misgaat
Eén keer repareren is niet genoeg. Je wil weten of het de volgende update ook overleeft. Dat vraagt om een kleine testprocedure die je elke keer uitvoert na een update.
Mijn aanpak na elke onderhoudssessie:
- Open de site in een incognitovenster
- Controleer of de cookiebanner verschijnt voordat er scripts van derden worden geladen
- Accepteer alle cookies en controleer in de browserconsole of de tracking-scripts nu wél laden
- Weiger alle cookies en controleer of die scripts dan uitblijven
- Controleer de toestemmingslog in het plugin-dashboard
Dit kost je drie minuten. Als je dit niet doet, ontdek je problemen pas als een klant belt — of als de AP op de stoep staat.
Verder helpt het om je updates niet allemaal tegelijk te doen. Werk plugins bij in kleine batches: eerst de cookieplugin apart, test, dan de rest. Zo weet je bij een probleem meteen welke update de oorzaak is. Gebruik je een stagingomgeving? Doe updates daar eerst. Heb je geen staging? Dan is het hoog tijd om dat te regelen bij je hoster.
Een back-up voor elke onderhoudssessie is geen optionele stap. Als de cookiebanner na een update kapot gaat en je hebt geen back-up van een uur geleden, ben je bezig met handmatig debuggen terwijl je site ondertussen non-compliant draait. Met een recente back-up herstel je in vijf minuten en debug je daarna rustig op een kopie.
Tot slot
Cookiebanners zijn saai. Niemand bouwt ze met plezier en niemand kijkt er graag naar. Maar ze zijn onderdeel van je technische verantwoordelijkheid als je een site beheert. Een kapotte cookiebanner is niet alleen een visueel probleem — het is een juridisch risico voor je klant.
Controleer na elke update of hij nog werkt. Houd een back-up bij. En als hij kapotgaat: begin bij de browserconsole, niet bij het plugin-dashboard. De console vertelt je in tien seconden of het een JavaScript-fout is of een laadprobleem. Dat scheelt je een halfuur rondklikken.