Een WordPress-pagina kan er voor bezoekers volledig normaal uitzien en toch buiten Google blijven. Dat komt doordat indexering niet alleen afhangt van wat je in de browser ziet. WordPress, je SEO-plugin, het thema, een cachinglaag, robots.txt en zelfs de webserver kunnen allemaal signalen toevoegen die bepalen of een zoekmachine de URL kan crawlen en indexeren.
Bij een indexeringsprobleem is het daarom verstandig om WordPress van boven naar beneden te controleren. Begin bij de eenvoudige instellingen en ga pas daarna naar broncode, canonicals en serverheaders. Zo voorkom je dat je ingewikkelde wijzigingen doet terwijl één vinkje de echte oorzaak is.
Deze handleiding is bedoeld voor gewone pagina’s, berichten en maatwerkposttypes op WordPress-websites.
Wat betekent ‘niet geïndexeerd’ precies?
Een pagina die niet geïndexeerd is, staat niet als zelfstandige URL in de zoekindex van Google. Dat is iets anders dan slecht ranken. Als de pagina wel in de index staat maar pas op positie 70 verschijnt, heb je een zichtbaarheidsprobleem. Wanneer Search Console aangeeft dat de URL niet is geïndexeerd, moet je eerst kijken naar toegankelijkheid en indexeringssignalen.
Gebruik de URL-inspectie in Google Search Console. Daar zie je vaak direct een concrete reden, zoals noindex, redirect, robots.txt of een status als “gecrawld, momenteel niet geïndexeerd”.
Controle 1: WordPress-instelling voor zoekmachines
WordPress heeft een algemene instelling waarmee je zoekmachines kunt ontmoedigen de site te indexeren. Deze optie wordt vaak gebruikt tijdens ontwikkeling.
Ga naar Instellingen > Lezen en controleer het onderdeel over zichtbaarheid voor zoekmachines. Bij een live bedrijfswebsite die in Google moet verschijnen, hoort deze instelling doorgaans niet aangevinkt te staan.
Belangrijk: deze optie is geen harde beveiliging. Ze is bedoeld als indexeringssignaal, niet om privé-inhoud af te schermen. Pagina’s die echt privé moeten blijven, beveilig je met toegangscontrole of authenticatie.
Na het wijzigen van deze instelling is het verstandig de cache te legen en de broncode opnieuw te controleren.
Controle 2: Yoast SEO of Rank Math staat op noindex
SEO-plugins kunnen indexering op meerdere niveaus regelen. Een individuele pagina kan op noindex staan, maar ook een volledig berichttype of archief kan worden uitgesloten.
In Yoast SEO controleer je bij de pagina de geavanceerde instellingen. In Rank Math vind je vergelijkbare robots-instellingen. Kijk of de pagina expliciet op noindex staat.
Controleer daarnaast de globale instellingen voor:
- pagina’s;
- berichten;
- categorieën;
- tags;
- auteursarchieven;
- custom post types;
- productcategorieën bij WooCommerce.
Vooral custom post types vormen een valkuil. Een kennisbankplugin kan bijvoorbeeld pagina’s openbaar tonen, terwijl de SEO-plugin dat berichttype standaard anders behandelt.
Controle 3: bekijk de echte robots-meta-tag
Vertrouw niet uitsluitend op het WordPress-dashboard. Uiteindelijk telt wat de server aan de crawler levert. Open de broncode van de pagina en zoek naar robots.
Een normale indexeerbare pagina kan bijvoorbeeld een robots-tag hebben die indexering toestaat. Zie je noindex, onderzoek dan waar die vandaan komt.
Mogelijke bronnen zijn:
- WordPress zelf;
- een SEO-plugin;
- een beveiligingsplugin;
- een stagingplugin;
- maatwerk in het thema;
- een serverheader met
X-Robots-Tag.
Die laatste zie je niet altijd in de HTML-broncode. Bij hardnekkige gevallen moet je daarom ook de response headers controleren.
Controle 4: staat de pagina in de XML-sitemap?
WordPress heeft zelf sitemapfunctionaliteit en veel SEO-plugins maken een uitgebreidere sitemapindex. Gebruik bij voorkeur één duidelijke sitemapoplossing.
Open de sitemap die je in Search Console hebt ingediend en zoek de URL. Als de pagina ontbreekt, controleer dan waarom. Soms is een pagina bewust uitgesloten omdat deze noindex is. In andere gevallen is het custom post type niet toegevoegd aan de sitemap.
Een pagina hoeft technisch niet in een sitemap te staan om geïndexeerd te kunnen worden, maar voor belangrijke content is opname wel een nuttig ontdekkingssignaal.
Let ook op verouderde sitemaps na een migratie. Een cachingplugin of CDN kan nog een oude versie tonen waarin nieuwe URL’s ontbreken.
Controle 5: de canonical wijst verkeerd
SEO-plugins voegen meestal automatisch een canonical toe. Bij een standaard WordPress-pagina verwijst deze doorgaans naar de pagina zelf. Toch kan het misgaan na dupliceren, importeren of migreren.
Stel dat je een pagina dupliceert om een nieuw dienstonderdeel te maken en de canonical handmatig op de oude pagina blijft staan. Dan zeg je in feite dat de oude URL de voorkeursversie is.
Controleer daarom:
- de canonical in de HTML;
- eventuele handmatige canonicalvelden in de SEO-plugin;
- de door Google geselecteerde canonical in Search Console;
- of www, https en slashvarianten consistent zijn.
Pas een canonical pas aan wanneer je begrijpt waarom deze bestaat. Bij e-commercefilters en echte duplicaten is canonicalisatie juist nuttig.
Controle 6: WordPress stuurt de URL door
Een pagina kan in het dashboard de status “gepubliceerd” hebben, terwijl de openbare URL een redirect geeft. Redirectplugins, gewijzigde slugs en oude migratieregels kunnen hiervoor zorgen.
Test de definitieve URL in een privévenster en controleer de HTTP-status. Kijk vooral naar:
- 301 permanente redirect;
- 302 tijdelijke redirect;
- redirectketens;
- redirectloops.
Als een pagina bewust is verhuisd, hoort Google uiteindelijk de bestemming te indexeren. Verwacht dan niet dat de oude URL als zelfstandige pagina zichtbaar blijft.
Controle 7: robots.txt blokkeert een belangrijk pad
Sommige WordPress-beheerders blokkeren complete mappen om crawlerbelasting te verminderen. Dat kan nuttig lijken, maar brede regels hebben soms onverwachte gevolgen.
Een custom post type kan bijvoorbeeld onder /kennisbank/ vallen. Als robots.txt toevallig /kennisbank/ blokkeert, kan Google de inhoud niet normaal crawlen.
Controleer robots.txt na iedere grote wijziging aan beveiliging, GTranslate, botfilters of performanceconfiguratie. Maak onderscheid tussen ongewenste scrapers blokkeren en legitieme zoekmachines de toegang tot belangrijke publieke content ontzeggen.
Controle 8: een beveiligingsplugin behandelt Google als botverkeer
WordPress-sites krijgen veel geautomatiseerd verkeer en beheerders installeren daarom regelmatig securityplugins of serverregels. Het risico is dat een brede blokkade ook zoekmachines raakt.
Voorbeelden:
- alle user-agents met “bot” worden geblokkeerd;
- rate limiting is te streng;
- bepaalde landen of IP-ranges worden uitgesloten;
- ModSecurity blokkeert requests naar specifieke paden;
- een bot-gate vereist cookies of JavaScript.
Een crawler kan dan een 403-, 429- of 5xx-response krijgen terwijl jij als ingelogde beheerder een normale pagina ziet.
Controleer serverlogs en Search Console als indexering plotseling stopt na een beveiligingswijziging.
Controle 9: de pagina is een orphan page
WordPress maakt het eenvoudig om URL’s aan te maken die nergens in het menu of de content worden genoemd. Zo’n orphan page heeft nauwelijks interne context.
Voor belangrijke pagina’s is het beter om een duidelijke plek in de informatiearchitectuur te kiezen. Een SEO-handleiding kan vanuit de SEO-categorie en een hoofdpagina over zoekmachineoptimalisatie worden gelinkt. Een commerciële WordPress-dienst kan vanuit de hoofdnavigatie of dienstenpagina bereikbaar zijn.
Maak interne links voor gebruikers, niet om kunstmatig zoveel mogelijk zoekwoorden te plaatsen. Goede links beantwoorden de vraag: “Waar wil iemand na dit onderdeel waarschijnlijk meer over weten?”
Controle 10: de tekst is een variant van andere pagina’s
Bij WordPress-sites met pagebuilders worden secties gemakkelijk gekopieerd. Dat is efficiënt voor design, maar inhoudelijk kan het leiden tot tientallen pagina’s die vrijwel hetzelfde zeggen.
Voor lokale SEO zie je bijvoorbeeld vaak pagina’s als “webdesign Eindhoven”, “webdesign Tilburg” en “webdesign Den Bosch” met exact dezelfde tekst en alleen een andere plaatsnaam. Wanneer elke pagina geen lokale of inhoudelijke meerwaarde heeft, is dat een zwakke basis.
Zorg dat iedere indexeerbare pagina zelfstandig bestaansrecht heeft. Gebruik unieke voorbeelden, specifieke vragen, eigen uitleg en relevante lokale of inhoudelijke details wanneer die werkelijk bestaan.
Controle 11: WordPress genereert meerdere versies van dezelfde inhoud
Afhankelijk van je thema en plugins kan dezelfde inhoud bereikbaar zijn via categorieën, tags, auteursarchieven, paginering of queryparameters. Dat is niet automatisch een probleem, maar een ondoordachte structuur kan veel overlap veroorzaken.
Bepaal welke URL’s echt zoekwaarde hebben. Een categoriepagina kan bijvoorbeeld waardevol zijn wanneer deze een duidelijke introductie, goede selectie en logische navigatie bevat. Een dun tagarchief met één artikel hoeft niet per se geïndexeerd te worden.
Zo voorkom je dat belangrijke pagina’s verdwijnen tussen grote aantallen minder nuttige URL’s.
Controle 12: je pagebuilder toont inhoud anders aan crawlers
Elementor, Gutenberg en de meeste moderne WordPress-thema’s produceren normale HTML. Toch kan maatwerkcontent afhankelijk zijn van JavaScript, AJAX of externe scripts.
Controleer vooral dynamische onderdelen zoals:
- filters;
- tabbladen;
- accordions;
- infinite scroll;
- popupcontent;
- content die na een API-call verschijnt.
Belangrijke pagina-inhoud en navigatielinks moeten betrouwbaar beschikbaar zijn. Een bezoeker zonder perfect werkend script moet nog steeds begrijpen waar de pagina over gaat.
Controle 13: de server is te traag of instabiel
Een technisch indexeerbare WordPress-pagina kan alsnog problemen opleveren wanneer de server geregeld time-outs geeft. Grote plugins, zware databasequeries, onvoldoende PHP-workers of mislukte cronjobs kunnen de site instabiel maken.
Kijk naar serverlogs rond het moment waarop crawlers de pagina bezoeken. 500-, 502- en 504-fouten zijn belangrijke signalen. Ook een overvolle database of enorme autoload-opties kunnen WordPress onnodig vertragen.
Performance is daarom niet alleen een Core Web Vitals-onderwerp. Betrouwbare serverrespons is een basisvoorwaarde om content goed te kunnen crawlen.
Controle 14: staginginstellingen zijn mee verhuisd
Na een migratie van staging naar live blijven soms instellingen achter die tijdens ontwikkeling logisch waren:
- noindex;
- wachtwoordbeveiliging;
- canonical naar het stagingdomein;
- absolute links naar de testsite;
- robots.txt-blokkades;
- HTTP-authenticatie;
- afwijkende DNS- of hostinstellingen.
Voer na iedere livegang daarom een vaste SEO-livecheck uit. Controleer niet alleen de homepage, maar ook een bericht, pagina, categorie en eventueel product.
Een praktische WordPress-indexeringscheck in 15 minuten
Wanneer één pagina ontbreekt, kun je deze volgorde gebruiken:
- open de URL zonder ingelogd te zijn;
- controleer de HTTP-status;
- open Search Console URL-inspectie;
- controleer WordPress > Instellingen > Lezen;
- controleer de robots-instelling in Yoast of Rank Math;
- controleer de canonical;
- zoek de URL in de sitemap;
- bekijk robots.txt;
- controleer interne links;
- vergelijk de pagina met inhoudelijk vergelijkbare URL’s;
- leeg caching als je instellingen hebt gewijzigd;
- test opnieuw en vraag eventueel indexering aan.
Bij veel problemen vind je binnen deze controle al de oorzaak.
Moet je plugins uitschakelen om het probleem te vinden?
Niet als eerste stap op een live website. Willekeurig plugins uitschakelen kan formulieren, caching, redirects of WooCommerce verstoren. Zoek eerst naar concrete aanwijzingen.
Denk je dat een plugin de oorzaak is? Test dan bij voorkeur op staging. Vergelijk de broncode en headers voor en na de wijziging. Zo werk je gecontroleerd in plaats van op goed geluk.
Veelgestelde vragen
Kan Yoast SEO voorkomen dat een WordPress-pagina in Google komt?
Ja, wanneer een pagina of berichttype op noindex is ingesteld. Yoast is dan niet “defect”; de plugin voert de gekozen indexeringsinstelling uit. Controleer daarom zowel de individuele pagina als de globale instellingen.
Kan Rank Math hetzelfde probleem veroorzaken?
Ook Rank Math beheert robots-instructies, canonicals en sitemapinstellingen. Een verkeerde configuratie kan dus leiden tot uitsluiting van een pagina.
Waarom staat de pagina wel in de sitemap maar niet in Google?
Een sitemap helpt Google de URL te ontdekken, maar garandeert geen indexering. Controleer de status in Search Console en beoordeel techniek, duplicatie en inhoudelijke waarde.
Moet ik tag- en categoriepagina’s indexeren?
Dat hangt af van hun functie. Een goed opgebouwde categoriepagina kan nuttig zijn. Dunne archieven zonder eigen waarde kunnen juist onnodige indexeerbare URL’s opleveren.
Is een SEO-plugin verplicht voor indexering?
Nee. WordPress kan zonder SEO-plugin worden geïndexeerd. Een goede SEO-plugin maakt beheer van titels, canonicals, robots-instructies en sitemaps wel eenvoudiger.
Conclusie
Wanneer een WordPress-pagina niet wordt geïndexeerd, ligt de oorzaak vaak in een combinatie van instellingen en inhoud. Controleer eerst de algemene WordPress-zichtbaarheid en de SEO-plugin, daarna robots-meta, sitemap, canonical, redirects en serverrespons. Kijk vervolgens of de pagina logisch intern gelinkt is en voldoende zelfstandig nut heeft.
Door indexering als onderdeel van je publicatieproces te behandelen, voorkom je dat nieuwe pagina’s ongemerkt maanden buiten de zoekresultaten blijven. Sanum Webdesign kan bij grotere WordPress-installaties technische SEO, indexeringsproblemen, sitemaps en sitearchitectuur gezamenlijk analyseren.
Bronnen voor redactionele controle: Google Search Central – SEO Starter Guide; Google Search Central – SEO Guide for Web Developers; Google Search Central – Spam Policies.
