Een loginmuur op een openbare SEO-pagina herkennen

Een sessiecookie, een bewaarde voorkeur of een ingelogd CMS-account verandert wat je ziet. Een pagina kan daardoor in jouw browser volledig leesbaar zijn en voor een anonieme bezoeker een aanmeldscherm tonen. Er zijn drie vormen. Bij een harde muur antwoordt de server met een redirect of een foutstatus. Bij een zachte muur antwoordt de server met 200, maar de zichtbare inhoud is een aanmeldformulier of een overlay. Bij een muur via script bevat de eerste HTML de inhoud of een lege app-shell, en stuurt JavaScript je daarna door of vervangt de inhoud.

Begin met een lijst van maximaal tien pagina's die publiek vindbaar moeten zijn: homepage, dienstpagina's, prijzen, contact en blogartikels. Noteer elke URL exact zoals die in je sitemap of menu staat. Een testresultaat zonder exacte URL is later niet te herhalen, zeker als er varianten bestaan met en zonder www of met en zonder afsluitende slash.

Voer per URL de volgende stappen uit en noteer de uitkomst in een blad met een rij per URL.

1. Anonieme response. Vraag de URL op met een hulpmiddel dat geen cookies meestuurt en redirects niet automatisch volgt, bijvoorbeeld de opdrachtregel of de netwerktab van je browser. Noteer de statuscode, een eventuele Location-header en of de hoofdtekst al in de ontvangen HTML staat.
2. Browser zonder cookies. Open een nieuw privévenster of een apart browserprofiel zonder aanmelding. Noteer de uiteindelijke URL in de adresbalk en wat je ziet na het laden. Let erop of de inhoud na enkele seconden verdwijnt of door een overlay bedekt wordt.
3. Vergelijk de HTML met het scherm. Staat de hoofdtekst alleen op het scherm en niet in de ontvangen HTML, dan hangt de inhoud van scripts af. Dat is een aparte bevinding.
4. Vergelijk met je ingelogde weergave. Elk verschil is een aandachtspunt voor de beheerder.

Houd de grens van deze test in het oog. Je test met jouw netwerk en jouw hulpmiddel, en een server kan bots, landen of IP-adressen anders behandelen. Een geslaagde browsertest bewijst dus geen crawltoegang voor Googlebot.

Een redirect naar een aanmeldpagina is bij een ledengedeelte een bewuste keuze. Op een publieke pagina is het meestal een fout of een neveneffect van een beveiligingsplugin, een firewallregel of een toegangsinstelling. Volg de keten stap voor stap: welke URL stuurt naar welke, via welk statustype, en eindigt de keten op één aanmeldadres, eventueel met een terugkeerparameter?

Dat laatste is belangrijk. Volgens de Google-uitleg over canonieke URL's is een redirect een sterk signaal dat het doel de canonieke pagina moet zijn, en een sitemap slechts een zwak signaal. Sturen tientallen publieke pagina's naar dezelfde aanmeldURL, dan geef je dat signaal mogelijk ongewild af. Controleer daarom ook of je sitemap adressen bevat die in werkelijkheid doorsturen, want dat zijn tegenstrijdige signalen. Gebruik robots.txt niet om dit te herstellen. Dezelfde bron meldt dat Google geblokkeerde adressen zonder inhoud kan indexeren, dus robots.txt is geen middel om een canonieke keuze te sturen.

Je eigen tests tonen een anoniem beeld, niet het beeld van Google. Daarvoor heb je Search Console nodig, waarvoor je eerst eigendom van de site verifieert. Google beschrijft een indexeringsrapport met een overzicht van pagina's die Google indexeerde of probeerde te indexeren. Het raadt een controle aan ongeveer elke maand en na wijzigingen aan de site. Hoe dat rapport in jouw account heet en waar het staat, kan veranderen. Laat de beheerder dat in de interface nakijken.

Gebruik voor één pagina de URL-inspectie en onderscheid twee dingen. De gegevens over de geïndexeerde versie tonen wat Google eerder verwerkte, inclusief de door Google gekozen canonical. De live test toont hoe de pagina nu wordt opgehaald. Lees de gekozen canonical dus uit de geïndexeerde data, niet uit de live test. Verschillen tussen beide kunnen erop wijzen dat een muur recent is geplaatst of weggehaald.

Bij JavaScript-sites is er een extra risico. Google legt uit dat het pagina's crawlt, rendert en indexeert, dat het eerst robots.txt leest en dat geblokkeerde scripts niet worden gerenderd. Bij een app-shell staat de echte inhoud pas na rendering in de pagina. Een script dat daarna doorstuurt naar aanmelden of de inhoud vervangt, kan dus ook het gerenderde resultaat veranderen. Niet alle bots voeren JavaScript uit.

Een pagina die bewust privé is, hoort niet in je sitemap. Een pagina die publiek hoort te zijn, heeft één bereikbare URL met een eigen canonical naar zichzelf.

Fictief scenario, alleen invoer en verwachte controles. Invoer: de pagina /diensten/onderhoud staat in het menu en in de sitemap. Je test drie keer: anonieme request, privévenster en URL-inspectie. De verwachte technische controles bij een gezonde pagina zijn: statuscode 200, geen Location-header, hoofdtekst in de ontvangen HTML, eindadres gelijk aan het gevraagde adres en een canonical die naar de pagina zelf wijst. In de geïndexeerde gegevens van URL-inspectie komt de door Google gekozen canonical overeen met jouw voorkeur. Wijkt een van die punten af, dan volg je de rij in het beslisblad.

Na elke wijziging herhaal je in deze volgorde: de drie tests op dezelfde URL's, de sitemap op adressen die doorsturen, de live test in URL-inspectie en een nieuwe controle van de geïndexeerde gegevens op een later moment. Of en wanneer Google de pagina opnieuw verwerkt, is onzeker. Noteer daarom datum, URL, wijziging en uitkomst in een overdrachtsnotitie voor de volgende beheerder.

Wil je ook weten welke publieke signalen je website zichtbaar maakt, bekijk ze dan via Marketing Scan. Een publieke scan meet alleen wat zichtbaar is en dekt niet alle controles uit deze gids.