Crawl discovery en crawl priority: onderzoek wat er met je URL gebeurt

Crawl discovery betekent dat Google een URL ontdekt. Crawl priority beschrijft de vraag welke bekende URL’s Google wanneer bezoekt, maar is geen zichtbare score die je kunt instellen. Wil je weten waarom een belangrijke pagina weinig wordt bezocht? Onderzoek dan afzonderlijk de vindroute, bewezen crawlerverzoeken, indexering en zoekzichtbaarheid. Met het werkblad in dit artikel bepaal je welk bewijs ontbreekt en welke gerichte ingreep je kunt toetsen.

Ontdekking, crawling, indexering en zichtbaarheid vragen ander bewijs

Een pagina publiceren maakt haar bereikbaar voor bezoekers die het adres kennen. Daarmee weet je nog niet of Google dat adres kent, de pagina heeft opgehaald of de inhoud in de zoekresultaten kan tonen. Ook een bekende URL hoeft niet onmiddellijk opnieuw te worden bezocht nadat je iets verandert.

Neem het fictieve adres /advies/onderhoud-houten-tafel. Je hebt een onderhoudsadvies geschreven en vanuit een productcategorie een link geplaatst. Die link is een mogelijke vindroute. Hij bewijst op zichzelf niet dat Google de link al heeft gevolgd.

Deze scheiding voorkomt een verkeerde opdracht aan je specialist. Bij een ontbrekende vindroute onderzoek je iets anders dan bij een opgehaalde pagina die niet wordt geïndexeerd. En wanneer een geïndexeerde pagina weinig passende vertoningen krijgt, kunnen onderwerpkeuze en inhoud relevanter zijn dan de bezoekfrequentie van Googlebot. Dan biedt zoekwoordenonderzoek naar de vragen van je doelgroep een ander onderzoeksspoor.

Crawl priority begrijpen via vraag en beschikbare capaciteit

Gebruik crawl priority als een praktische omschrijving van bezoekkeuzes, niet als een meetbare Google-instelling. Google beschrijft crawling aan de hand van crawl demand en crawl capacity. Dat onderscheid helpt om verklaringen te ordenen zonder een verborgen formule te verzinnen.

Crawl demand gaat over de vraag naar het ophalen van URL’s. Daarbij kunnen onder meer de bekende URL-inventaris, de uniekheid van inhoud, populariteit en veroudering meespelen. Je kunt daaruit geen eigen prioriteitsscore per pagina afleiden. Een optelsom van interne links, klikken en vertoningen is dus geen berekening van Googles bezoekplanning.

Crawl capacity gaat over wat Google kan ophalen zonder de website te zwaar te belasten. Serverbeschikbaarheid en de afhandeling van verzoeken zijn daarbij relevant. Als verzoeken regelmatig mislukken of de server moeilijk reageert, is technisch onderzoek gerechtvaardigd. Dat betekent niet dat iedere snellere pagina automatisch vaker wordt bezocht.

Een inhoudelijke verandering kan een reden geven om opnieuw naar een pagina te kijken. Een gewijzigde publicatiedatum zonder aangepaste inhoud biedt daarentegen geen onderbouwing voor een versheidsclaim. Noteer daarom wat daadwerkelijk veranderde: bijvoorbeeld een aangepaste montagehandleiding, nieuwe productspecificaties of het verdwijnen van een assortiment.

De Google-documentatie over crawlbudget richt zich vooral op grote of vaak veranderende websites en omvangrijke ontdekkingsproblemen. Een kleine bedrijfswebsite met enkele ontbrekende pagina’s heeft meestal eerst een gerichte controle nodig. Maak er niet vooraf een breed crawlbudgetproject van.

Verzamel eerst gegevens met een bekende dekking

Begin met een korte lijst belangrijke URL’s en de reden waarom je ze onderzoekt. Bijvoorbeeld: een nieuwe dienstpagina verschijnt niet in URL-inspectie, gewijzigde levertijdinformatie lijkt nog niet opgehaald of het aantal verzoeken aan een productgroep neemt af. Houd waarneming en verklaring vanaf het begin uit elkaar.

Controleer in Search Console of je toegang hebt tot de juiste, geverifieerde property. Let op protocol, hostnaam en eventuele subdomeinen. Bewaar de inspectiedatum, de gerapporteerde laatste crawldatum en de indexeringsstatus. Die gegevens kunnen over verschillende momenten gaan; behandel ze niet alsof ze gelijktijdig zijn gemeten.

Vraag voor logs welke laag wordt geregistreerd. Een CDN kan een pagina zelf leveren, waardoor het verzoek niet bij de originserver terechtkomt. Alleen originlogs doorzoeken kan dan een onvolledig beeld geven. Controleer ook of logs voor alle onderzochte hosts beschikbaar zijn, of er bewaargaten zijn en welke tijdzone wordt gebruikt.

Een regel met de user-agent Googlebot is onvoldoende bewijs van een Google-verzoek. Die naam kan worden nagebootst. Laat de afzender controleren tegen de gepubliceerde IP-bereiken of via reverse-DNS, gevolgd door een overeenkomende forward-DNS-controle. De officiële instructies voor het verifiëren van Google-verzoeken beschrijven deze methoden.

Leg bovendien vast welk soort verzoek je ziet. Een door jou gestarte live test moet herkenbaar blijven als test. Die bewijst dat ophalen op dat moment lukt, maar is geen bewijs dat Google de pagina tijdens een reguliere crawl heeft bezocht of geïndexeerd.

Werkblad: leg per URL bewijs, vermoedens en ontbrekende gegevens vast

Maak voor iedere onderzochte URL een kopie van de onderstaande onderzoekskaart. Je kunt de velden overnemen in een spreadsheet of document. Het is een statisch werkblad: het haalt geen gegevens op en bepaalt geen Googleprioriteit. De waarde zit in het naast elkaar zetten van bewijs en open vragen.

Gebruik bijvoorbeeld de woorden vastgesteld, vermoed en onbekend voor iedere belangrijke notitie. Daarmee voorkom je dat een aanname tijdens overleg ongemerkt een feit wordt. Een vinkje bij sitemap en interne link zegt alleen dat die routes zijn gecontroleerd. Twee vinkjes betekenen niet meer crawl priority dan één vinkje.

Het werkblad kan drie bruikbare uitkomsten ondersteunen: een onderbouwde wijziging uitvoeren, aanvullende gegevens verzamelen of voorlopig niets wijzigen. Ook die laatste keuze kan passend zijn wanneer een stabiele, geïndexeerde pagina minder vaak wordt bezocht en er geen functioneel probleem zichtbaar is.

Fictieve kaart 1: een nieuwe adviespagina zonder vastgesteld bezoek

Alle adressen, datums en waarnemingen in de drie kaarten hieronder zijn fictief. Ze laten zien hoe je het werkblad invult; het zijn geen uitkomsten van een uitgevoerde websitecontrole.

• URL en functie: /advies/tafel-voor-kleine-eetkamer helpt bezoekers een passende tafelmaat kiezen.
• Vindroute: op 4 september gecontroleerd in de sitemap; op de categoriepagina ontbreekt een verwijzing.
• Meetperiode: 1 tot en met 14 september, UTC. Alleen originlogs beschikbaar; de CDN-dekking is onbekend.
• Laatste waargenomen bezoek: onbekend. In de beschikbare logs is geen geverifieerd verzoek gevonden.
• Antwoordstatus: onbekend voor Googlebot. Een eigen bereikbaarheidstest op 14 september geeft HTTP 200.
• Indexeringsbewijs: URL-inspectie van 14 september meldt ontdekt, momenteel niet geïndexeerd, zonder laatste crawldatum.
• Vastgesteld: Google kent de URL volgens de opgeslagen inspectiegegevens; de pagina is bij de eigen test bereikbaar.
• Vermoeden en alternatief: beperkte interne vindbaarheid kan meespelen; een ontbrekend CDN-log kan daarnaast verklaren waarom geen verzoek is teruggevonden.
• Onbekende gegevens: volledige logdekking en een eventueel recenter verzoek dan de opgeslagen inspectiestatus.
• Eigenaar: de webbeheerder verzamelt CDN-gegevens; de redacteur beheert de verwijzende categoriepagina.
• Gerichte ingreep: voeg een beschrijvende link toe waar bezoekers daadwerkelijk hulp bij maatkeuze nodig hebben.
• Vervolgmeting: controleer gedurende de vooraf gekozen volgende veertien dagen geverifieerde verzoeken en inspecteer daarna de indexeringsstatus afzonderlijk.

Fictieve kaart 2: een bezochte filterpagina die niet is geïndexeerd

• URL en functie: /tafels?breedte=80 laat bezoekers het assortiment op breedte beperken.
• Vindroute: een werkende filterlink op de tafelscategorie, gecontroleerd op 14 september.
• Meetperiode: 1 tot en met 14 september, UTC, met volledige CDN-logs voor de onderzochte host.
• Laatste waargenomen bezoek: 11 september om 09.20 uur; Googlebot-afzender geverifieerd tegen de toepasselijke IP-bereiken.
• Antwoordstatus: HTTP 200 bij het vastgelegde verzoek.
• Indexeringsbewijs: URL-inspectie van 14 september meldt gecrawld, momenteel niet geïndexeerd.
• Vastgesteld: de URL is opgehaald. De bewaarde response bevat een canonical naar de algemene tafelscategorie.
• Vermoeden en alternatief: de site presenteert de categorie als voorkeursversie; beperkte onderscheidende inhoud kan eveneens relevant zijn. De status bewijst geen van beide als oorzaak.
• Onbekende gegevens: of een zelfstandige zoeklandingspagina voor deze maat een nuttige eigen functie heeft.
• Eigenaar: de webshopbeheerder bepaalt samen met de SEO-specialist het doel van deze URL.
• Gerichte ingreep: documenteer eerst of dit uitsluitend een navigatiefilter blijft. Verander de canonical pas als een zelfstandige indexeerbare pagina inhoudelijk gerechtvaardigd is.
• Vervolgmeting: controleer na een eventuele wijziging response, canonical en indexeringsstatus; behoud daarnaast een controle op de bruikbaarheid van het filter.

Fictieve kaart 3: minder bezoeken aan een bestaande servicepagina

• URL en functie: /service/onderhoud-eikenblad helpt bestaande klanten hun tafel onderhouden.
• Vindroute: links vanuit het serviceoverzicht en relevante productpagina’s, gecontroleerd op 14 september.
• Meetperiode: 1 tot en met 14 augustus tegenover 1 tot en met 14 september, beide UTC, met dezelfde volledige CDN-logdekking.
• Laatste waargenomen bezoek: 12 september om 16.10 uur; de Googlebot-afzender is geverifieerd.
• Antwoordstatus: HTTP 200 bij alle getelde verzoeken.
• Indexeringsbewijs: URL-inspectie van 14 september vermeldt de pagina als geïndexeerd met zichzelf als canonieke URL.
• Vastgesteld: acht verzoeken in de eerste periode en vier in de tweede; de inhoud is niet veranderd.
• Vermoeden en alternatief: stabiele inhoud kan samengaan met minder herbezoek; normale variatie blijft een andere verklaring.
• Onbekende gegevens: de reden waarom Google het bezoekschema veranderde.
• Eigenaar: de webbeheerder bewaakt bereikbaarheid; de serviceverantwoordelijke controleert of het advies actueel blijft.
• Gerichte ingreep: geen inhoud wijzigen uitsluitend om een nieuw bezoek uit te lokken. Corrigeer alleen aantoonbaar verouderde instructies.
• Vervolgmeting: vergelijk een volgende gelijklange periode en controleer indexering en bereikbaarheid opnieuw.

De fictieve afname is vier verzoeken op een uitgangswaarde van acht: (4 - 8) / 8 × 100 = -50%. Dat percentage klinkt groot, maar betreft vier verzoeken verschil. Het rekensommetje beschrijft de waarneming en verklaart haar niet. Er volgt geen oordeel over kwaliteit, rankings of klantgebruik uit.

Onderzoek een nieuwe URL zonder vastgesteld bezoek

Controleer eerst het exacte adres. Een slash, parameter, redirect of andere hostnaam kan maken dat je in rapporten naar een andere URL kijkt dan de URL die uiteindelijk wordt geleverd. Noteer zowel het aangevraagde adres als een eventuele eindbestemming.

1. Controleer bereikbaarheid. Werkt de pagina zonder inloggen? Welke status wordt geleverd? Is er een redirectketen of een serverfout?
2. Controleer toegang en indexeerbaarheid. Bekijk robotsregels, noindex en de canonical. Een blokkade of instructie kan bewust zijn; stel het paginadoel vast voordat je iets verwijdert.
3. Controleer vindroutes. Is er een bruikbare interne link? Staat de juiste URL in een toegankelijke sitemap? Een publicatie in je CMS alleen is geen gecontroleerde vindroute.
4. Vergelijk Search Console met geverifieerde logs. Noteer datums en dekking. Een opgeslagen status en een recenter logverzoek kunnen verschillende momenten beschrijven.
5. Kies pas daarna een actie. Herstel een bewezen fout, verbeter een ontbrekende vindroute of verzamel eerst ontbrekende gegevens.

Volgens de uitleg van het pagina-indexeringsrapport betekent ontdekt, momenteel niet geïndexeerd dat Google de URL heeft gevonden maar nog niet heeft gecrawld; de laatste crawldatum is dan leeg. Gecrawld, momenteel niet geïndexeerd beschrijft juist een opgehaalde pagina die niet in de index staat. Geen van beide meldingen bewijst op zichzelf lage kwaliteit.

Een succesvolle live test na een eerdere fout laat zien dat ophalen nu lukt. Bewaar beide datums. Je kunt daarmee een eerder bereikbaarheidsprobleem onderzoeken, maar nog niet vaststellen dat de indexering is bijgewerkt. Wanneer de gegevens elkaar niet voldoende aanvullen, is onvoldoende bewijs de juiste conclusie.

Onderzoek afgenomen crawlactiviteit met een vergelijkingsperiode

Begin bij de meting zelf. Zijn beide perioden even lang? Worden dezelfde hosts, paden en crawlercategorieën geteld? Is een logginginstelling gewijzigd? Een daling door ontbrekende CDN-gegevens vraagt herstel van je meetbasis, geen aanpassing van honderden pagina’s.

Vergelijk vervolgens statuscodes en bereikbaarheid. Een overgang van succesvolle antwoorden naar time-outs of serverfouten is een concreet technisch spoor. Controleer ook of een firewall, botfilter of hostingwijziging samenvalt met de afname. Zoek daarbij naar het tijdstip waarop het gedrag verandert, niet alleen naar maandtotalen.

Bekijk daarna wijzigingen aan de website. Minder nieuwe producten, verwijderde parameterlinks, nieuwe canonicals of een andere navigatie kunnen de URL-inventaris en vindroutes veranderen. Splits productpagina’s, categorieën, filters en artikelen uit. Een daling bij overbodige varianten heeft een andere betekenis dan uitblijvende bezoeken aan gewijzigde productinformatie.

Gebruik Search Console voor aanvullende informatie over crawling, indexering en prestaties. Houd die signalen gescheiden: minder bezoeken en minder vertoningen in dezelfde periode bewijzen nog geen oorzakelijk verband. Laat bij meerdere onduidelijke signalen een SEO-audit met een afgebakende onderzoeksvraag beginnen bij de betrokken URL-groep en beschikbare gegevens.

Kies de ingreep die past bij het gevonden probleem

Je kunt interne vindbaarheid verbeteren, inhoud aanpassen, serverproblemen herstellen of werkelijk overbodige URL’s opruimen. Deze acties lossen verschillende problemen op. Leg daarom vooraf vast welke waarneming je keuze ondersteunt en wat na uitvoering aantoonbaar anders moet zijn.

Diepe pagina’s: herstel een logische route

Een pagina die alleen via meerdere onduidelijke tussenstappen bereikbaar is, verdient een controle van de navigatie. Er bestaat geen universele regel dat iedere pagina binnen drie klikken moet liggen. Vraag waar iemand deze informatie verwacht en welke bestaande pagina daar een bruikbare verwijzing kan bieden.

Gebruik doorgaans een link met een a-element en een oplosbaar href. Maak de linktekst beschrijvend en passend bij de bestemming. Een belangrijke pagina hoort vanaf minstens één andere pagina op de site bereikbaar te zijn via een interne link. Meer links plaatsen zonder inhoudelijke reden levert geen meetbare prioriteitsscore op.

Begin bij interne links en de samenhang tussen pagina’s als vindroutes het probleem zijn. Controleer na de wijziging de geleverde link en bestemming. Google beschrijft de technische basis in zijn richtlijnen voor crawlbare links.

Filters en paginering: beoordeel de navigatiefunctie afzonderlijk

Een filterfunctie kan bezoekers helpen zonder dat iedere combinatie een zelfstandige zoeklandingspagina nodig heeft. Maak onderscheid tussen een nuttige selectie, een inhoudelijk waardevolle categorie en een eindeloze verzameling combinaties met vrijwel dezelfde uitkomst.

Blokkeer daarom niet standaard alle filters. Bepaal eerst welke selecties bereikbaar moeten blijven, welke pagina’s zelfstandig indexeerbaar bedoeld zijn en welke URL-varianten onnodig ontstaan. Canonicals geven een voorkeursversie aan, maar alleen de vorm van de URL bewijst niet dat twee pagina’s duplicaten zijn.

Bewaar noodzakelijke paginering en zorg voor afzonderlijke, bereikbare adressen waar dat nodig is om door het assortiment te navigeren. Voorkom onnodige tijdelijke of sessieparameters in links. Voor deze keuzes verbindt ecommerce-SEO de technische URL-structuur met de manier waarop klanten producten vinden.

Verouderde inhoud: kies behouden, samenvoegen of verwijderen op functie

Weinig organisch verkeer is onvoldoende reden om een pagina te verwijderen. Een onderhoudsinstructie kan bestaande klanten helpen. Een tijdelijk uitverkocht product kan terugkomen. Onderzoek daarom eerst wie de pagina nodig heeft en of de informatie nog klopt.

Behouden past bij bruikbare, actuele inhoud. Bijwerken past wanneer de functie blijft bestaan maar de uitleg achterhaald is. Samenvoegen kan passend zijn wanneer twee pagina’s vrijwel dezelfde taak vervullen en één volledige bestemming duidelijker is. Gebruik een redirect alleen naar een inhoudelijk passende vervanger.

Is inhoud blijvend verdwenen en bestaat er geen passende vervanger, dan kan HTTP 404 of 410 correct zijn. Een lege pagina met HTTP 200 kan juist een soft 404 opleveren. Stuur ook niet iedere verdwenen productpagina naar de homepage. Laat inhoudelijke beoordeling van SEO-content voorafgaan aan de keuze voor behouden of verwijderen.

Noindex moet worden opgehaald voordat Google de instructie kan zien. Een robotsblokkade is daarom geen vervanging voor het verwijderen van een URL uit de index. Stem toegang, indexeringsinstructies en antwoordstatus af op het daadwerkelijke paginadoel.

Serverproblemen: toets of verzoeken betrouwbaar worden afgehandeld

Bij foutmeldingen of sterk wisselende antwoordtijden ligt de eerste taak bij de technische beheerder. Onderzoek of het probleem ontstaat in de applicatie, hosting, CDN of beveiligingslaag. Controleer de getroffen URL-groep: één zwaar filter kan ander gedrag vertonen dan een gewone dienstpagina.

Voer daarna een gerichte oplossing uit en controleer opnieuw dezelfde verzoeken en meetpunten. Een betere visuele laadtijd voor bezoekers is nuttig, maar bewijst op zichzelf geen verandering in crawl capacity. Voor dit onderzoek gaat het om aantoonbare bereikbaarheid en betrouwbare antwoorden. Technische SEO helpt deze controles koppelen aan de betrokken pagina’s en instellingen.

Een sitemap helpt ontdekken, maar plant geen gegarandeerd bezoek

Gebruik in een sitemap de canonieke URL van iedere pagina die je als indexeerbare bestemming wilt aanbieden. Controleer of deze adressen bereikbaar zijn en overeenkomen met je interne links en canonicalkeuzes. Een sitemap vol redirects, verdwenen pagina’s of onbedoelde varianten geeft geen helder overzicht van de gewenste pagina’s.

Het veld lastmod kan relevante wijzigingsinformatie geven. Vul het in op basis van een betekenisvolle verandering aan de pagina. Iedere dag voor alle URL’s een nieuwe datum genereren maakt de informatie minder bruikbaar als weergave van inhoudelijke wijzigingen.

Google negeert de sitemapvelden priority en changefreq. Een hogere waarde instellen geeft je dus geen handmatige knop voor crawl priority. Een sitemap ondersteunt ontdekking en kan wijzigingsinformatie bevatten, maar garandeert geen herbezoek of indexering. Dit onderscheid staat in de documentatie over het bouwen van sitemaps.

Voor enkele beheerde URL’s kun je via URL-inspectie indexering aanvragen als je eigenaar of volledige gebruiker bent. Er geldt een quotum. Voor veel URL’s is een sitemap de aangewezen route. Herhaald aanvragen voor dezelfde URL versnelt crawling niet; alleen de melding gecrawld, momenteel niet geïndexeerd is geen reden om voortdurend opnieuw in te dienen.

Volg de instructies voor het aanvragen van een nieuwe crawl zonder er een vaste termijn aan te verbinden. Een aanvraag garandeert geen snelle crawl, indexering of opname in zoekresultaten. De gespecialiseerde Indexing API is geen algemene inzendroute voor gewone artikelen.

Toets één wijziging met een nulmeting en vergelijkbare URL-groepen

Formuleer eerst een toetsbare verwachting. Bijvoorbeeld: belangrijke handleidingen zonder relevante interne verwijzing worden mogelijk onvoldoende gevonden. De ingreep is dan een passende link vanaf de bijbehorende productpagina. Je verandert tijdens deze toets niet tegelijk de teksten, canonicals en sitemapdatums van dezelfde handleidingen.

Kies vergelijkbare URL-groepen op basis van paginatype, ouderdom, functie en uitgangssituatie. Laat één groep de wijziging krijgen en houd een andere groep voorlopig gelijk. Dat maakt een vergelijking bruikbaarder, al is het geen volledig gecontroleerd experiment: Google bepaalt zelf welke URL’s het bezoekt.

Leg voor beide groepen een nulmeting vast. Noteer per URL bewezen verzoeken, antwoordstatussen, laatste waargenomen bezoek en indexeringsstatus. Kies vooraf een observatieperiode die past bij het bestaande bezoekpatroon en de beschikbare logs. Als er normaal weinig bezoeken zijn, kan een korte periode onvoldoende informatie opleveren. De periode is een meetafspraak, geen belofte van resultaat.

Stel fictief dat je twee groepen van elk twaalf handleidingen onderzoekt. In een nulmeting van 21 dagen hebben vijf pagina’s in de eerste groep en zes in de tweede groep minstens één geverifieerd verzoek. Dat is respectievelijk ongeveer 42% en 50%. Bewaar daarnaast de verzoekaantallen per pagina: één veelbezochte URL mag het beeld van de hele groep niet verbergen.

Deze fictieve cijfers beschrijven alleen het vertrekpunt. Na de wijziging vul je de werkelijke vervolggegevens in. Vergelijk bezoekfrequentie, het aantal verschillende bezochte URL’s, statuscodes en indexering afzonderlijk. Meer verzoeken aan een foutpagina zijn geen verbetering van bereikbaarheid. Meer succesvolle verzoeken zijn evenmin bewijs van betere rankings.

Registreer gelijktijdige veranderingen, zoals een storing, een nieuwe navigatie, een productimport of een gewijzigde loginstelling. Als zulke veranderingen de vergelijking verstoren, benoem je de uitkomst als onzeker. Een volgende observatieperiode kan zinvol zijn; achteraf alleen gunstige dagen selecteren maakt de toets onbetrouwbaar.

Neem de conclusie op in je SEO-rapportage met vier onderdelen: wat is veranderd, wat is gemeten, welke verklaring wordt ondersteund en wat blijft onbekend. Zo kan een ondernemer beoordelen of vervolgwerk gerechtvaardigd is, ook wanneer de uitkomst geen aantoonbare verandering laat zien.

Veelgestelde vragen over ontbrekende en veranderende crawlerbezoeken

Waarom is mijn nieuwe pagina nog niet bezocht?

Controleer eerst bereikbaarheid, interne vindroutes, sitemap en de gedateerde status in Search Console. Vergelijk die gegevens met geverifieerde logs waarvan de dekking bekend is. Zonder volledige logs kun je een ontbrekend verzoek niet bewijzen. Een ontdekte URL zonder vastgesteld bezoek geeft op zichzelf geen oordeel over de kwaliteit van de pagina.

Kan ik crawl priority handmatig verhogen?

Er is geen zichtbare Googleprioriteit die je zelf kunt instellen. Je kunt technische fouten herstellen, relevante interne links toevoegen en inhoudelijke wijzigingen correct doorgeven. Voor enkele URL’s kun je indexering aanvragen. Die acties garanderen geen herbezoek, en herhaalde aanvragen voor dezelfde URL versnellen crawling niet.

Zorgt een snellere website voor meer crawling?

Betrouwbare, efficiënte serverantwoorden kunnen relevant zijn voor crawl capacity. Onderzoek daarom eerst of trage antwoorden of serverfouten daadwerkelijk voorkomen bij crawlerverzoeken. Een hogere snelheidsscore voor bezoekers bewijst geen extra crawling. Meet na herstel de bereikbaarheid, antwoordstatussen en bezoekfrequentie afzonderlijk.

Waarom is een sitemap geen garantie dat Google mijn pagina bezoekt?

Een sitemap biedt URL’s aan en kan met een betekenisvolle lastmod aangeven dat inhoud is gewijzigd. Google bepaalt zelf wanneer het een URL ophaalt en of het die indexeert. Gebruik canonieke, indexeerbare URL’s. De velden priority en changefreq worden door Google genegeerd en dwingen geen bezoek af.

Wat betekent het als Google mijn pagina minder vaak bezoekt?

Een afname kan verschillende verklaringen hebben, waaronder meetverschillen, technische problemen, veranderde vindroutes of stabiele inhoud. Vergelijk gelijklange perioden met dezelfde logdekking en controleer statuscodes en indexering. Minder bezoeken bewijzen geen kwaliteitsdaling en zijn zonder verdere diagnose geen reden om een bruikbare pagina te verwijderen.

Laat drie belangrijke URL’s gericht beoordelen

Kies één nieuwe pagina, één bezochte maar niet geïndexeerde pagina en één pagina met afgenomen bezoeken. Vul voor iedere URL de onderzoekskaart zo ver mogelijk in. Laat ontbrekende gegevens zichtbaar staan; je hoeft geen verklaring te bedenken waar nog geen bewijs voor is.

Niblah biedt webdesign voor WordPress en Shopify en ondersteuning bij SEO. Wil je laten beoordelen welke technische of inhoudelijke vervolgstap bij jouw website past? Stuur via het Niblah-contactformulier de drie URL’s, hun bezoekersfunctie, de onderzochte periode en de beschikbare Search Console-statussen. Vermeld ook of geverifieerde logs beschikbaar zijn. Daarmee maak je de vraag concreet: wat weten we al, welk bewijs ontbreekt en welke wijziging verdient als eerste een toets?