Category: Nederlands

Mist er in het indexeringsrapport van Search Console een stuk van juni 2026, dan is er niets mis met je site en komen die gegevens niet terug. Google zegt indexeringsdata niet achteraf aan te vullen. Mijn mening: gebruik dat rapport niet als enige bron voor wat er geïndexeerd is, en hou zelf een logboek bij.

Wat is er met het indexeringsrapport gebeurd?

Het rapport Pagina-indexering gebruiken de meeste mensen om te zien welke URL’s Google heeft geïndexeerd en waarom andere zijn overgeslagen. In juni 2026 bleef het stilstaan. Volgens de berichtgeving van Search Engine Land, samengevat door ALM Corp, stond het rapport ongeveer drie weken op de gegevens van 11 juni. Op de ochtend van 3 juli werd het bijgewerkt, met cijfers tot 29 juni. Een openbare verklaring van Google over de oorzaak was er toen niet.

Wie in die periode een indexeringsprobleem aan het oplossen was, had pech: je kon een noindex-tag weghalen, een redirect repareren of een sitemap opnieuw indienen, en het rapport kon niet laten zien of het werkte.

Het tweede deel volgde op 11 september. Site-eigenaren, onder wie Dan Lauer op Bluesky, zagen dat een stuk juni-data dat uren eerder nog zichtbaar was, weg was. Barry Schwartz meldde het op Search Engine Roundtable. John Mueller antwoordde dat het gat waarschijnlijk komt van de periode in juni waarin de data vertraagd was: het rapport werd toen niet bijgewerkt, dus er valt niets te tonen. Google’s standpunt, in zijn woorden: “We don’t back-fill indexing data.”

Betekent een gat in het rapport dat mijn pagina’s uit de index zijn?

Nee. Een ontbrekende periode in de grafiek zegt dat Google voor die dagen geen rapportdata heeft vastgelegd. Het zegt niet dat pagina’s uit de index zijn gehaald. Het zijn twee verschillende systemen: de index levert zoekresultaten, het rapport is een verslaglaag daaroverheen.

Schadelijk is vooral de verwarring. Vergelijk je het huidige aantal geïndexeerde pagina’s met een junicijfer dat niet meer bestaat, dan denk je misschien pagina’s kwijt te zijn die je nooit kwijt was. Vergelijk alleen met data die er wel is, en controleer belangrijke pagina’s met de URL-inspectietool (Engelstalige uitleg).

Hoe hou ik zelf bij welke pagina’s geïndexeerd zijn?

De les van juni is simpel: een rapport dat je niet zelf beheert kan te laat, bevroren of onvolledig zijn. Een klein logboek kost tien minuten per maand.

• Exporteer het rapport periodiek. Het rapport Pagina-indexering heeft een exportfunctie. Sla de lijsten met geïndexeerde en niet-geïndexeerde pagina’s maandelijks op, met de datum in de bestandsnaam, of na elke grote wijziging.
• Hou een lijst bij van de URL’s die ertoe doen. Nieuwe artikelen, belangrijke pagina’s en alles wat je hebt gerepareerd. Noteer per URL de publicatiedatum, de datum van je indexeringsverzoek en de status die je zag.
• Inspecteer belangrijke URL’s rechtstreeks. De URL-inspectie toont de laatste crawldatum en of de pagina op Google staat, los van de grafiek.
• Lees je serverlogs. Googlebot-verzoeken in de logs van je hosting laten zien wanneer een pagina echt is opgehaald, wat Search Console ook toont.
• Voeg een tweede zoekmachine toe. Bing Webmaster Tools geeft je een apart beeld van wat gevonden en geïndexeerd is, en ondersteunt IndexNow.

Hoeveel kun je nu op indexeringsrapporten vertrouwen?

Vertrouw ze voor de richting, niet voor het cijfer van één dag. Search Console had eerder dit jaar rapportagevertragingen en begin september nog een rapportagestoring, dus een dip van een dag of een vlakke week is zwak bewijs. Sterker bewijs is een geleidelijke verandering over meerdere weken, of iets wat je met een directe URL-inspectie bevestigt.

Dat geldt ook na de spamupdate van september 2026 (Engelstalig artikel). Wil je weten of die update pagina’s naar “Gecrawld – momenteel niet geïndexeerd” heeft geduwd, dan heb je een schone voor-en-nameting nodig. Je eigen export van vóór 24 september is meer waard dan een grafiek met gaten. Blijven pagina’s hangen, begin dan bij gecrawld versus ontdekt en hoe lang het duurt voordat Google je pagina indexeert.

Veelgestelde vragen

Google leest wie een afbeelding maakte, wie je moet vermelden en waar de licentie staat op twee plekken: IPTC-fotometadata in het bestand zelf en ImageObject-structured data op de pagina. Voeg je een licentie-URL toe, dan komen je afbeeldingen in aanmerking voor het label Licentie (Licensable) in Google Afbeeldingen. Wij deden dit bij alle afbeeldingen op deze site, en ontdekten dat je hosting de helft ervan ongemerkt kan weghalen.

Welke afbeeldingsmetadata leest Google?

Google gebruikt afbeeldingsmetadata om in Google Afbeeldingen te tonen wie achter een afbeelding zit en hoe je hem mag gebruiken. Die informatie kan uit het bestand zelf komen (IPTC-fotometadata, opgeslagen als IPTC of XMP) of uit structured data op de pagina. Dit zijn de velden die tellen:

Bij structured data is alleen contentUrl verplicht, plus minstens één van creator, creditText, copyrightNotice of license. Google koppelt de metadata via contentUrl aan de juiste afbeelding, dus dat moet de echte URL van het afbeeldingsbestand zijn.

Hoe krijg je het licentielabel in Google Afbeeldingen?

Het licentielabel in Google Afbeeldingen linkt naar je licentie en laat zien hoe iemand de afbeelding mag gebruiken. Googles regel is kort: met IPTC moet je de Web Statement of Rights invullen, met structured data moet je license opnemen. Beide wijzen naar een pagina met de voorwaarden.

Dat hoeft geen betaalde licentiewinkel te zijn. Op onze pagina Image use & credit staat dat je onze afbeeldingen gratis mag delen, met een bronvermelding en een link naar het artikel. Ook dat is een licentie, en zo wordt elke gekopieerde afbeelding een mogelijke backlink.

IPTC of structured data: wat gebruik je?

Allebei, als dat kan. Ze doen elk iets anders:

• Structured data vertrouwt Google het meest. De documentatie zegt dat Google bij tegenstrijdige informatie de structured data gebruikt. Het staat bovendien op je eigen pagina, dus niemand kan het weghalen.
• IPTC-metadata reist mee met het bestand. Downloadt iemand je afbeelding en plaatst hij die ergens anders, dan kunnen maker en licentie-URL meegaan, tenzij onderweg iets ze weghaalt.

In WordPress met Yoast SEO staat de hoofdafbeelding van een artikel al als ImageObject in het schema. Wij hebben daar creator, creditText, copyrightNotice, license en acquireLicensePage aan toegevoegd met een klein filter op het schema van Yoast. Zo krijgt elke bestaande en toekomstige afbeelding dezelfde velden.

Wat er gebeurde bij onze 42 afbeeldingen

Op 26 september 2026 hebben we de hoofdafbeelding van elk artikel op deze site opnieuw gemaakt: met een zichtbare balk met de URL van het artikel, de auteur en het jaar, en met metadata die we met ExifTool in IPTC, XMP en EXIF schreven. Daarna hebben we de live bestanden gedownload zoals een browser ze krijgt. Onze hosting levert afbeeldingen via een CDN dat ze opnieuw omzet, vaak naar WebP, en die omzetting bepaalde wat er overbleef.

De optimalisatie liet dus precies de rechteninformatie staan en gooide de rest weg. Voor de bronvermelding is dat genoeg, maar je kunt voor omschrijving en trefwoorden niet op het bestand vertrouwen. Die horen in de alt-tekst, het bijschrift en op de pagina zelf.

Nog twee kleinere lessen. Het ©-teken raakte verminkt in de IPTC Copyright Notice na de omzetting. Daarom schrijven we daar nu “Copyright 2026 IndexUrePoint” en gebruiken we het © alleen in XMP. En IPTC-velden hebben harde lengtegrenzen: Credit Line en Source mogen maar 32 tekens bevatten, dus “IndexUrePoint.com” past wel en een volledige URL niet.

Hoe controleer je je eigen afbeeldingen?

Vertrouw niet op het bestand op je eigen computer; controleer het bestand dat bezoekers en Googlebot krijgen. Met ExifTool geïnstalleerd:

curl -s -o live.jpg https://example.com/wp-content/uploads/image.jpg
curl -s -o live.webp -H "Accept: image/webp" https://example.com/wp-content/uploads/image.jpg
exiftool -G1 -s -Creator -Rights -WebStatement -Credit -CopyrightNotice live.jpg live.webp

De tweede regel vraagt om WebP, zoals Chrome dat doet. Juist daar verdwijnt metadata vaak. Daarna:

• Test de pagina in Googles test voor rich results om te zien of het ImageObject een license en contentUrl heeft.
• Kijk in Search Console onder Optimalisaties naar het rapport Metadata van afbeelding. Bij ons verscheen het binnen enkele dagen nadat we de metadata hadden toegevoegd. Je pagina’s moeten wel eerst gecrawld zijn, dus meld je site aan bij Google als dat nog niet is gebeurd.

En AI-afbeeldingen?

Google leest het IPTC-veld Digital Source Type en ondersteunt vier waarden voor AI, waaronder trainedAlgorithmicMedia (gemaakt door een generatief model) en compositeWithTrainedAlgorithmicMedia (een samengestelde afbeelding met AI-materiaal). De basis van onze illustraties komt uit een AI-beeldmodel, en elk woord en getal erop voegen wij zelf toe. Daarom labelen we ze als samengesteld.

Onze hosting haalde dat veld echter weg. Daarom zeggen we het ook in gewone woorden op onze pagina over afbeeldingsgebruik. Wil je AI-afbeeldingen eerlijk labelen, vertrouw dan niet alleen op het veld in het bestand.

Zet je je URL op de afbeelding zelf?

Metadata is onzichtbaar en kwetsbaar; pixels niet. Screenshots, sociale media en AI-tools laten metadata vaak vallen, maar een kleine balk met je domein en de URL van het artikel overleeft ze allemaal. Daarom staat onder elke afbeelding op deze site nu het eigen adres.

Afbeeldingen als startpunt van een zoekopdracht worden zo belangrijk dat Google ze apart rapporteert: met het nieuwe multimodale filter in Search Console zie je verkeer via Lens en Circle to Search.

Houd het bescheiden: een dunne balk, geen watermerk over het onderwerp heen. Maak voor sociale media een aparte versie van 1200×630, zodat platforms je balk er niet af snijden.

Veelgestelde vragen

AI-bedrijven gebruiken verschillende crawlers voor verschillende taken — trainen, zoeken en ophalen namens een gebruiker — en met robots.txt sta je elk daarvan apart toe of blokkeer je hem: laat de zoekcrawlers binnen als je geciteerd wilt worden, en beslis bewust over de trainingscrawlers.

Welke AI-crawlers zijn er in 2026?

De grote AI-bedrijven splitsen hun crawlers inmiddels op naar taak. Dat is goed nieuws: je hoeft niet meer te kiezen tussen “alles open” en “alles dicht”.

• OpenAI: GPTBot verzamelt trainingsdata voor de modellen. OAI-SearchBot bepaalt of je in ChatGPT-zoeken verschijnt. ChatGPT-User haalt een pagina op wanneer een gebruiker daarom vraagt; volgens OpenAI zijn robots.txt-regels daar mogelijk niet van toepassing. Nieuw is OAI-AdsBot, dat pagina’s controleert die als advertentie in ChatGPT worden aangeboden.
• Anthropic: ClaudeBot voor training, Claude-SearchBot voor zoekkwaliteit en Claude-User voor ophalen op verzoek van een gebruiker. Anthropic zegt robots.txt en Crawl-delay te respecteren.
• Perplexity: PerplexityBot bouwt de zoekindex en wordt volgens Perplexity niet gebruikt voor modeltraining. Perplexity-User haalt pagina’s op tijdens een vraag en negeert robots.txt volgens de eigen documentatie “in het algemeen”.
• Google: Google-Extended is geen aparte crawler maar een token in robots.txt; het crawlen gebeurt met de gewone Google-user-agents.
• Apple: Applebot-Extended bepaalt of Apple je content voor AI-training mag gebruiken.

Welke AI-crawlers moet je toestaan?

Voor de meeste bedrijfssites, blogs en webshops is de verstandige standaard: zoekcrawlers toestaan. Als ChatGPT, Claude of Perplexity een vraag beantwoordt waar jij het beste antwoord op hebt, wil je als bron genoemd worden. Hoe je die kans vergroot, lees je in GEO-optimalisatie.

Over trainingscrawlers kun je verschillend denken. Is je content zelf het product — betaald onderzoek, cursusmateriaal, een database — dan is blokkeren verdedigbaar. Is je content bedoeld om gevonden te worden, dan levert blokkeren weinig op en kan het op termijn betekenen dat modellen je merk minder goed kennen.

Wat doet Google-Extended precies?

Google-Extended bepaalt of content die Google crawlt gebruikt mag worden voor het trainen van toekomstige Gemini-modellen en voor grounding in Gemini Apps en Vertex AI. Google schrijft er uitdrukkelijk bij dat Google-Extended geen invloed heeft op opname in Google Zoeken en geen rankingsignaal is.

Belangrijk voor wie denkt zich zo uit AI Overviews te houden: AI Overviews zijn onderdeel van Google Zoeken en werken met de gewone Googlebot-index. Google-Extended blokkeren haalt je daar dus niet uit. Wel kun je sinds 31 augustus 2026 je hele site uitsluiten van AI Overviews en AI Mode met de instelling Generatieve AI in Zoeken in Search Console (Instellingen), zonder uit de gewone zoekresultaten te verdwijnen — uitleg in onze gids over AI Overviews in Search Console (Engels). Wil je een pagina helemaal niet in Google, dan heb je noindex nodig — niet robots.txt.

Hoe zit het met Bing en Microsoft Copilot?

Microsoft werkt anders: er is geen aparte AI-crawler om te blokkeren. Copilot en de AI-antwoorden in Bing gebruiken de gewone Bing-index, gevuld door Bingbot. Blokkeer je Bingbot, dan verdwijn je uit Bing én uit Copilot.

In plaats daarvan gebruikt Bing metatags. Volgens de aankondiging van Microsoft betekent nocache dat alleen URL, titel en fragment in chatantwoorden mogen verschijnen, en noarchive dat je content daar helemaal niet wordt gebruikt — terwijl je gewoon in de zoekresultaten blijft staan. De actuele lijst staat in Bings overzicht van ondersteunde robots-metatags. Hoe vaak Copilot je al citeert, zie je in het AI Performance-rapport van Bing Webmaster Tools.

Voorbeeldregels voor robots.txt

Variant 1 — AI-zoeken toestaan, AI-training blokkeren:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

Zoekcrawlers als OAI-SearchBot, Claude-SearchBot en PerplexityBot noem je niet; die mogen dan standaard alles, net als Googlebot en Bingbot.

Variant 2 — alles toestaan (zoals op deze site):

User-agent: *
Disallow:

Sitemap: https://indexurepoint.com/sitemap_index.xml

Variant 3 — één map afschermen voor één bot:

User-agent: GPTBot
Disallow: /premium/

Test elke wijziging in het robots.txt-rapport van Search Console en onthoud dat robots.txt een verzoek is, geen slot. Een pagina die je in robots.txt blokkeert, kan bovendien nog steeds in Google verschijnen — zonder beschrijving. Zie geblokkeerd door robots.txt.

Hoe controleer je welke AI-bots je site bezoeken?

• Serverlogs: zoek in je access-logs naar de user-agent-namen uit de tabel hierboven. De meeste hostingpartijen laten je de ruwe logs downloaden.
• CDN of firewall: Cloudflare en vergelijkbare diensten tonen botverkeer per user-agent en laten je AI-bots per categorie toestaan of weren. Let op dat zo’n instelling niet stilletjes ook Bingbot of Googlebot tegenhoudt.
• Echtheid controleren: iedereen kan zich GPTBot noemen. OpenAI, Google en anderen publiceren IP-reeksen waarmee je kunt nagaan of een bezoek echt van hen komt.
• Resultaat meten: kijk in je analytics naar verwijzend verkeer van chatgpt.com, perplexity.ai en copilot.microsoft.com.

Wat gaat er vaak mis?

• Alles blokkeren uit voorzorg. Een regel als User-agent: * met Disallow: /, of een beveiligingsplugin die “alle AI-bots” weert, houdt je ook uit AI-zoeken.
• Denken dat GPTBot = ChatGPT-zoeken. Dat zijn twee bots met twee rollen. Controleer welke je precies blokkeert.
• Typefouten in de botnaam. GPT-Bot of Claudebot-Search bestaan niet; een onbekende naam wordt genegeerd.
• Bingbot per ongeluk blokkeren. Daarmee verdwijn je uit Copilot én uit de bron waar ChatGPT-zoeken zwaar op leunt.
• Verwachten dat het direct werkt. OpenAI en Perplexity noemen allebei tot ongeveer 24 uur voordat een wijziging verwerkt is.

Voorbeeld: zo doen we het op deze site

IndexUrePoint laat alle crawlers toe; onze robots.txt bestaat alleen uit User-agent: *, een lege Disallow en de verwijzing naar de sitemap. Daarnaast serveren we een /llms.txt (uitleg in het Engels) met een overzicht van onze Engelse en Nederlandse gidsen. Eerlijk is eerlijk: geen van de grote AI-bedrijven heeft bevestigd dat ze llms.txt gebruiken bij het bepalen van bronnen. Het kost niets en schaadt niet, maar het vervangt geen goede robots.txt, sitemap en indexering.

Test je regels direct met onze gratis robots.txt-tester (Engels): in één klik zie je of GPTBot, ClaudeBot en Googlebot worden toegelaten of geblokkeerd.

Veelgestelde vragen

Bing Webmaster Tools is de gratis tegenhanger van Google Search Console van Microsoft: je ziet hoe Bing je site crawlt, indexeert en rankt — en sinds februari 2026 ook hoe vaak Microsoft Copilot je pagina’s als bron noemt in AI-antwoorden.

Wat is Bing Webmaster Tools?

Bing Webmaster Tools is een gratis dashboard van Microsoft voor website-eigenaren. Het laat zien welke pagina’s Bing heeft gevonden en geïndexeerd, op welke zoekopdrachten je verschijnt, welke sites naar je linken en welke technische problemen Bing tegenkwam tijdens het crawlen. Microsoft heeft ook een Nederlandstalige helppagina, al is het dashboard zelf grotendeels Engelstalig.

Microsofts eigen Webmaster Guidelines beschrijven inmiddels hoe Bing content toont in Bing-zoekresultaten, in Copilot en in resultaten van de grounding-API. Met andere woorden: dezelfde index voedt de klassieke zoekmachine, Microsofts AI-assistent én externe diensten die hun antwoorden op Bing baseren.

Waarom doet Bing ertoe als Google 90% marktaandeel heeft?

Omdat de Bing-index veel verder reikt dan bing.com. In Nederland had Google in augustus 2026 bijna 90% van de zoekopdrachten en Bing ongeveer 3,7% (StatCounter); wereldwijd was dat 91,1% tegen 4,5%. Maar AI-assistenten veranderen die rekensom.

Seer vergeleek de bronnen van ChatGPT met de resultaten van Google en Bing voor dezelfde vragen: Bing kwam voor 87% overeen, Google voor 56%. Dat is niet het hele verhaal — experimenten waarover Semrush rapporteerde wijzen erop dat betaalde ChatGPT-versies ook Google gebruiken — maar de les is eenvoudig: als Bing je niet kan indexeren, mis je in een groot deel van de AI-antwoorden. Daarom zien wij Bing als pijler van GEO-optimalisatie, niet als bijzaak.

Hoe stel je Bing Webmaster Tools in? (10 minuten)

Microsofts Getting Started Checklist noemt dezelfde basisstappen. Zo verliepen ze op deze site.

Stap 1 — Inloggen

Ga naar bing.com/webmasters en log in met een Microsoft-, Google- of Facebook-account. Een aparte registratie is niet nodig.

Stap 2 — Site toevoegen

Je hebt twee keuzes. Importeren uit Google Search Console is het snelst: je geverifieerde properties en hun sitemaps komen mee zonder aparte verificatie, maar je geeft Bing leestoegang tot je Search Console-gegevens. Handmatig toevoegen betekent je URL invullen en zelf verifiëren. Wij kozen handmatig, om de accounts gescheiden te houden. Heb je Search Console nog niet ingesteld? Begin dan met je website aanmelden bij Google.

Stap 3 — Eigendom verifiëren

Er zijn drie methoden: een XML-bestand (BingSiteAuth.xml) in de hoofdmap van je site, een msvalidate.01-metatag op je homepage, of een CNAME-record in je DNS. Op WordPress is de metatag het eenvoudigst — Yoast SEO heeft er een veld voor. Wij plaatsten de tag, klikten op Verify, en de site verscheen direct in het dashboard.

Stap 4 — Sitemap indienen

Open Sitemaps → Submit sitemap en vul je sitemap-URL in — met Yoast of Rank Math meestal /sitemap_index.xml. Die van ons stond binnen enkele seconden op “Processing”. Meldt Bing een fout, dan zijn de oorzaken dezelfde als bij Google: zie sitemap kan niet worden gelezen.

Stap 5 — IndexNow koppelen

Installeer de officiële IndexNow-plugin (of zet IndexNow aan in je SEO-plugin), zodat elke nieuwe of gewijzigde URL direct naar Bing gaat. Op het moment van schrijven had deze site 100 IndexNow-meldingen verstuurd, zonder één mislukking. Meer daarover in wat is IndexNow.

Hoe verhoudt Bing Webmaster Tools zich tot Google Search Console?

De basis overlapt, de extra’s verschillen. Bing is gulder met gratis onderzoeksdata; Google heeft het grootste publiek.

Ook in de praktijk vallen die extra’s op: in een r/bigseo-discussie met de titel “Anyone here actively using Bing Webmaster Tools?” noemt iemand de backlinkdata “surprisingly good”.

Wat laat het AI Performance-rapport zien?

Microsoft introduceerde AI Performance op 10 februari 2026 als openbare preview. Het rapport dekt Microsoft Copilot, AI-samenvattingen in Bing en een aantal partnerintegraties, met vijf weergaven: totaal aantal vermeldingen, gemiddeld aantal geciteerde pagina’s, grounding-zoekvragen, vermeldingen per pagina en de trend in de tijd. Op 13 oktober 2026 voegde Microsoft daar Topics Portfolio (bèta) aan toe, dat de grounding-zoekvragen waarbij je site verschijnt groepeert in bredere thema’s.

De beperkingen zijn belangrijk. Zoals Search Engine Land opmerkte, meten de cijfers alleen hoe vaak je wordt geciteerd — geen klikken, geen verkeer en geen indicatie van hoe prominent je bron werd gebruikt. Zie het als een zichtbaarheidssignaal en controleer echte bezoeken in je analytics. Wil je vaker geciteerd worden, pas dan de aanpak uit GEO-optimalisatie toe, en zorg dat je de crawler van Microsoft niet blokkeert — zie AI-crawlers en robots.txt.

Waar past IndexNow in?

Bing Webmaster Tools laat zien wat Bing over je site weet; IndexNow is de manier om Bing direct te vertellen dat er iets veranderd is. In plaats van te wachten tot Bingbot opnieuw langskomt, stuurt je site bij elke nieuwe, gewijzigde of verwijderde URL een seintje naar Bing. In het IndexNow-onderdeel van het dashboard zie je wat er binnenkwam.

Handmatig URL’s indienen kan nog steeds — Bing verhoogde het dagquotum van 10 naar maximaal 10.000 URL’s, afhankelijk van hoe lang een site al geverifieerd is (Search Engine Journal) — maar IndexNow doet hetzelfde automatisch. Google doet niet mee aan IndexNow; voor Google blijf je afhankelijk van sitemaps en interne links. Hoe lang dat duurt, lees je in hoe lang duurt indexeren bij Google.

Kun je Bing Webmaster Tools koppelen aan ChatGPT, Claude of BigQuery?

Niet met een officiële koppeling met één klik: Microsoft publiceert er geen voor ChatGPT, Claude, BigQuery, Google Sheets, Looker Studio of Power BI (gecontroleerd op 17 oktober 2026). Wat Microsoft wel biedt, is de Bing Webmaster API, en elke werkende koppeling loopt daarlangs.

Toegang krijg je op twee manieren: met OAuth 2.0, dat Microsoft aanraadt voor apps, of met een API-key. Voor de key open je Bing Webmaster Tools en klik je op Settings (rechtsboven) → API Access → Generate API Key; de eerste keer accepteer je eerst de voorwaarden. Per gebruiker kan er maar één key worden aangemaakt. De key hoort bij je gebruikersaccount en niet bij één site, dus behandel hem als een wachtwoord. Denk je dat hij is uitgelekt, verwijder hem dan en maak een nieuwe; apps die de oude key gebruikten, werken daarna niet meer.

De API dekt dezelfde data als de belangrijkste rapporten. Bruikbare methoden in de officiële referentie zijn onder meer GetQueryStats en GetPageStats (verkeer voor je belangrijkste zoekopdrachten en pagina’s), GetPageQueryStats, GetRankAndTrafficStats, GetCrawlStats, GetCrawlIssues, GetUrlInfo, GetKeywordStats, SubmitUrl en SubmitUrlBatch. Het AI Performance-rapport staat niet in de API-referentie; citatiedata blijven dus voorlopig in het dashboard.

Voor de meeste sites is de eenvoudigste nuttige opzet een wekelijks script dat zoekopdracht- en paginastatistieken in een sheet of BigQuery-tabel zet, naast je Search Console-data. Zo zie je naast elkaar welke pagina’s Google en Bing echt indexeren en welke zoekopdrachten elke zoekmachine stuurt. Die vergelijking is ook de snelste manier om te zien of Bing achterloopt, wat volgens het onderzoek hierboven direct doorwerkt in ChatGPT-zoeken; zie GEO-optimalisatie.

Wat gaat er mis — en hoe los je het op?

• “Is het überhaupt de moeite waard?” — een veelgehoorde twijfel, bijvoorbeeld in deze r/growmybusiness-discussie. Tien minuten instellen levert je Bing, Copilot en een deel van de bronnen van ChatGPT op. Ja, het is de moeite waard.
• Geïndexeerd volgens het dashboard, maar onvindbaar. Een gebruiker op r/bing meldde dat zijn site uit de index was verdwenen terwijl het portaal hem nog als geïndexeerd toonde. Gebruik de live-check van URL Inspection en bevestig met een site:-zoekopdracht op Bing.
• Bingbot geblokkeerd. Een firewall- of robots.txt-regel die Googlebot wel doorlaat maar Bingbot niet, houdt je ongemerkt buiten de deur. Controleer beide — zie geblokkeerd door robots.txt.
• Verificatie verdwijnt. Bing controleert de verificatie opnieuw. Haal je de metatag weg tijdens een redesign, dan verlies je de toegang.
• Pagina’s gevonden maar niet geïndexeerd. Bing slaat, net als Google, dunne of dubbele pagina’s over. De oplossingen uit gecrawld vs. gevonden en canonieke URL’s gelden hier ook.
• Dubbele IndexNow-meldingen. Meerdere plugins die dezelfde URL’s insturen, verspillen quotum. Kies één methode.

Hoe ging het op deze site, van nul naar geïndexeerd?

Na het koppelen van IndexNow publiceerden we op 24 september 2026 negen nieuwe gidsen. Elke publicatie ging automatisch als IndexNow-melding naar Bing, en de sitemap werd tegelijk bij Google ingediend. Aan de Google-kant waren acht van de negen gidsen een dag later al geïndexeerd — geholpen door interne links vanaf pagina’s die al in de index stonden. Die combinatie van sitemap, IndexNow en interne links is precies wat we hierboven aanraden: niets ervan kost geld, alles is in een middag geregeld.

Veelgestelde vragen

“Sitemap kan niet worden gelezen” of “Kan niet worden opgehaald” betekent dat Google je sitemap probeerde te laden en dat dat mislukte — verkeerde URL, een blokkade, kapotte XML, of gewoon een verse indiening die nog verwerkt wordt.

De check van 2 minuten

De echte oorzaken

• Verkeerde URL. Yoast en Rank Math gebruiken /sitemap_index.xml; WordPress zonder SEO-plugin /wp-sitemap.xml. Uit gewoonte /sitemap.xml indienen is de klassieke fout.
• Geblokkeerd voor Googlebot door robots.txt, een beveiligingsplugin, firewall of botbescherming.
• Kapotte XML: lege regels of PHP-waarschuwingen vóór <?xml, of een cacheplugin die een geminificeerde HTML-versie serveert.
• Te groot. Eén sitemap mag maximaal 50.000 URL’s of 50 MB (ongecomprimeerd) bevatten.
• Serverfouten of time-outs op het moment dat Google hem ophaalde.
• Net ingediend. Bij nieuwe sites toont het rapport vaak een tijd “Kan niet worden opgehaald”, ook als het bestand prima is.

Oplossingen die werken

• Dien de exacte URL in die je plugin maakt en verwijder oude inzendingen.
• Sluit sitemaps uit van cache en minificatie en laat Googlebot door in je beveiligingsinstellingen.
• Valideer de XML met een online sitemap-validator.
• Zet de sitemap in robots.txt met een Sitemap:-regel, zodat ook Bing hem vindt.
• Dien na het oplossen één keer opnieuw in. Vaker helpt niet.

Veelgestelde vragen

“Pagina met omleiding” betekent dat de URL bezoekers doorstuurt, waardoor Google de bestemming indexeert — meestal precies de bedoeling. De kwade tweeling “Fout met omleiding” (lussen, lange ketens) moet je wél altijd repareren.

Wat “Pagina met omleiding” betekent

Normaal of oplossen?

• Normaal: http → https, met of zonder www, oude slugs na het hernoemen van een bericht, verwijderde pagina’s doorverwezen naar een echte vervanger.
• Oplossen: doorverwijzende URL’s in je XML-sitemap. Een sitemap hoort alleen definitieve, indexeerbare URL’s te bevatten.
• Oplossen: menu’s en interne links die naar een doorverwijzende URL wijzen. Link direct naar de eindbestemming.
• Oplossen: een pagina die je wilt laten ranken maar onverwacht doorverwijst — vaak een pluginregel of taal-doorverwijzing.

“Fout met omleiding” — die moet je oplossen

Deze aparte status betekent dat Google de doorverwijzing niet kon afmaken: een te lange keten, een lus, een URL die te lang werd, of een lege of kapotte URL in de keten. Test de URL met URL-inspectie en laat elke oude URL in één 301-stap naar de eindbestemming gaan.

Een uitgewerkt voorbeeld

Stel: je hernoemt een artikel van /seo-tips/ naar /seo-tips-2026/. WordPress maakt automatisch een redirect van de oude naar de nieuwe slug. In Search Console verschijnt de oude URL daarna als “Pagina met omleiding” — correct, geen actie nodig. Wél actie nodig: je interne links en eventuele menu-items nog naar /seo-tips/ laten wijzen. Elke klik en elke crawl maakt dan een extra stap. Werk je een jaar later de titel opnieuw bij naar /seo-tips-2027/, controleer dan of de oudste URL rechtstreeks naar de nieuwste gaat, en niet via de tussenversie — zo houd je elke omleiding op één stap en blijft “Fout met omleiding” buiten de deur.

Veelgestelde vragen

Een soft 404 is een pagina die de browser “200 OK” meldt maar er voor Google leeg of verdwenen uitziet — dus behandelt Google hem als niet gevonden en blijft hij uit de index.

Wat een soft 404 is

De zes gebruikelijke oorzaken

• Eigen “niet gevonden”-pagina’s die 200 teruggeven in plaats van 404.
• Lege categorie-, tag- of zoekpagina’s met alleen “Geen producten gevonden”.
• Uitverkochte of verlopen items die zijn teruggebracht tot een titel en “niet meer leverbaar”.
• Doorverwijzen naar een irrelevante pagina, vooral massaal verwijderde URL’s naar de homepage sturen.
• Dunne placeholderpagina’s: “binnenkort beschikbaar”, bijna lege templates.
• Weergaveproblemen. JavaScript dat voor Googlebot faalt, waardoor Google een lege pagina ziet.

Oplossen per paginatype

• Pagina bestaat niet meer? Geef een 404 of 410 en haal hem uit je sitemap en interne links.
• Vervangen? 301 naar de meest vergelijkbare pagina — niet naar de homepage.
• Webshop: houd tijdelijk uitverkochte producten online met volledige informatie, alternatieven en een verwachte leverdatum.
• JavaScript-site: gebruik URL-inspectie → Live URL testen → Geteste pagina bekijken. Is de schermafbeelding leeg, los dan eerst de weergave op.
• WordPress: controleer dat je 404-template echt een 404-status geeft, en zet lege tagarchieven op noindex.

Een uitgewerkt voorbeeld

Een webshop haalt vijftig uitverkochte producten offline en stuurt alle oude URL’s naar de homepage. Twee weken later staan ze in Search Console als soft 404: de redirect zegt “verhuisd”, maar de homepage is geen vervanger voor een specifiek product. De juiste route was per product kiezen: is er een opvolger, stuur dan daarheen met een 301; is er alleen een passende categorie, stuur daarheen; is er niets vergelijkbaars, geef dan een echte 404 of 410 en haal de URL uit de sitemap. Na die correctie verdwijnen de meldingen vanzelf bij de volgende crawlronde — soft 404’s op bewust verwijderde pagina’s die netjes 404 geven, zijn daarna geen probleem meer.

Veelgestelde vragen

“URL geblokkeerd door robots.txt” betekent dat je robots.txt Googlebot verbiedt de pagina te crawlen — en omdat robots.txt cràwlen regelt en niet indexeren, kan een geblokkeerde URL alsnog kaal in Google belanden.

“URL geblokkeerd door robots.txt”

Je robots.txt (op jouwsite.nl/robots.txt) bevat een Disallow-regel die op deze URL past. Voor beheerpagina’s, winkelwagens en interne zoekresultaten is dat precies de bedoeling. Voor artikelen en productpagina’s is het een fout.

Veelvoorkomende ongelukjes: een achtergebleven Disallow: / van een testsite, een te brede regel zoals Disallow: /p die ook /producten/ raakt, of een plugin die het bestand herschreef.

“Geïndexeerd, maar geblokkeerd door robots.txt”

Google kan een URL indexeren die hij niet mag crawlen als er genoeg links naartoe wijzen. Hij toont dan de URL met weinig of geen beschrijving. Wat je doet hangt af van wat je wilt:

Beide statussen oplossen

• Open het robots.txt-rapport in Search Console (Instellingen → robots.txt). Het toont welke versie Google ophaalde, wanneer, en eventuele fouten.
• Zoek de regel die past. Regels werken op het begin van het pad: Disallow: /blog blokkeert ook /blog-tips/.
• Pas voorzichtig aan. In WordPress kan dat via Yoast (Extra → Bestandseditor) of Rank Math. Blokkeer nooit CSS of JavaScript die je pagina’s nodig hebben.
• Houd de sitemapregel erin: Sitemap: https://jouwsite.nl/sitemap_index.xml.
• Valideer. Klik op “Oplossing valideren” of vraag indexering aan voor de belangrijkste pagina’s.

Een uitgewerkt voorbeeld

Een sitebeheerder wil interne zoekresultaten uit Google houden en zet Disallow: /?s= in robots.txt én een noindex op de zoekpagina’s. Klinkt dubbel veilig, maar het bijt elkaar: door de Disallow mag Google de pagina’s niet meer lezen en ziet hij de noindex dus nooit. URL’s met veel inkomende links kunnen dan als kale resultaten blijven staan — precies de melding “Geïndexeerd, maar geblokkeerd door robots.txt”. De juiste volgorde: eerst alleen de noindex laten staan tot de pagina’s uit de index zijn, en pàs daarna eventueel de Disallow toevoegen om crawlbudget te sparen. Andersom werkt het nooit.

AI-crawlers: wil je GPTBot, ClaudeBot of Google-Extended apart toestaan of blokkeren, lees dan AI-crawlers en robots.txt — met voorbeeldregels per bot.

Test je regels direct met onze gratis robots.txt-tester (Engels): je ziet welke regel een URL blokkeert voor Googlebot.

Veelgestelde vragen

Ziet Google meerdere vrijwel identieke URL’s, dan indexeert hij er precies één: de canonieke versie. De drie canonieke meldingen in Search Console vertellen alleen wie die keuze maakte — jij, Google, of allebei eens.

Wat “canoniek” betekent

Google groepeert pagina’s met (vrijwel) dezelfde inhoud en indexeert er één. Jij kunt een voorkeur aangeven met een rel=”canonical”-tag, je sitemap, interne links en doorverwijzingen. Maar Google behandelt die tag als een hint, geen bevel. Spreken je signalen elkaar tegen, dan kiest Google zelf.

De drie meldingen — en wat ze betekenen

De derde, “Alternatieve pagina met correcte canonieke tag”, is meestal goed nieuws: de pagina verwijst netjes naar een andere canonieke versie en Google is het ermee eens. Die kun je doorgaans negeren — tenzij er een unieke pagina tussen staat die je juist wél in Google wilt.

Welke heb jij? Controle in 60 seconden

Oplossingen die werken (in deze volgorde)

• Laat je signalen overeenkomen. Sitemap, canonical, interne links en doorverwijzingen moeten allemaal dezelfde URL noemen. Tegenstrijdige signalen zijn de nummer-één-oorzaak.
• Geef elke belangrijke pagina een canonical naar zichzelf. Yoast SEO en Rank Math doen dit automatisch; controleer de paginabron op rel=”canonical”.
• Ruim dubbele varianten op. http en https, www en zonder www, met en zonder slash aan het eind: stuur alles met een 301 door naar één versie.
• Versterk de URL die je wilt. Link er intern naartoe vanaf sterke, al geïndexeerde pagina’s.
• Voeg echte duplicaten samen. Twee bijna gelijke pagina’s? Maak er één sterke pagina van en verwijs de andere door.
• Taalversies? Elke taalversie is zijn eigen canonieke pagina; koppel ze met hreflang, niet met een canonical.

Veelgestelde vragen

“URL gemarkeerd als noindex” betekent dat Google je pagina heeft gecrawld, een instructie vond om hem niet te indexeren en die heeft opgevolgd — de enige vraag is of jij die instructie bewust hebt geplaatst.

Wat de melding betekent

Waar een noindex zich verstopt

• De robots-metatag in de HTML: <meta name=”robots” content=”noindex”>. Bekijk de paginabron en zoek op “noindex”.
• De X-Robots-Tag-header, ingesteld door server, CDN of plugin. Onzichtbaar in de paginabron — URL-inspectie laat het zien bij “Indexeren toegestaan?”.
• “Zoekmachines ontmoedigen” in WordPress (Instellingen → Lezen). Eén vinkje dat de hele site op noindex zet.
• Instellingen van je SEO-plugin. Yoast: “Zoekmachines toestaan deze inhoud in zoekresultaten te tonen?” per bericht en per inhoudstype. Rank Math: de Robots Meta-instelling.
• Onderhouds- of “binnenkort beschikbaar”-plugins die zolang ze actief zijn een noindex toevoegen.

Stap voor stap weghalen

• Bevestig het met URL-inspectie (live test). Daar zie je of de noindex in de metatag of in de header zit.
• Los de bron op, niet alleen de pagina. Staat een heel berichttype op noindex, dan erft elk nieuw bericht dat.
• Leeg je cache. Paginacache en CDN kunnen de oude HTML nog even serveren.
• Zorg dat de pagina niet in robots.txt geblokkeerd is — Google moet hem kunnen crawlen om de wijziging te zien. Zie Geblokkeerd door robots.txt.
• Vraag indexering aan voor belangrijke pagina’s en klik op “Oplossing valideren” voor de rest.

Een uitgewerkt voorbeeld

Een bedrijf lanceert zijn nieuwe site en de weken erna komt er geen enkele pagina in Google. Paniek, backlinks gekocht, niets helpt. De echte oorzaak: tijdens de bouw stond “Zoekmachines ontmoedigen om deze site te indexeren” aan, en niemand zette het vinkje na de lancering uit. Eén instelling, weken verlies. Daarom is dit de eerste controle in elke indexeringsdiagnose: Instellingen → Lezen in WordPress, daarna URL-inspectie op de homepage. Staat daar “Indexeren toegestaan? Nee: ‘noindex’ gedetecteerd”, dan weet je binnen een minuut waar je moet zijn — en na het uitzetten en opnieuw aanvragen stonden in dit soort gevallen de eerste pagina’s er binnen dagen in.

Veelgestelde vragen