Welke belangrijke pagina ontbreekt in Google, en hoort juist die URL vindbaar te zijn? Begin bij die vraag wanneer je indexeren in Google Search Console onderzoekt. Vergelijk je eigen paginaoverzicht met Pagina-indexering, controleer afwijkingen per adres en gebruik Sitemaps en Verwijderingen alleen voor hun eigen doel. Met het fictieve Dossier Binnenlijn hieronder maak je van losse meldingen concrete besluiten, zonder onbekende gegevens voor fouten aan te zien.
Bepaal eerst welke URL je wilt laten indexeren
Een bestaande URL is niet automatisch een gewenst zoekresultaat. Een productpagina kan zelfstandig bezoekers helpen, terwijl dezelfde producten in een andere sorteervolgorde geen aparte ingang nodig hebben. Een oud adres kan naar zijn opvolger verwijzen. Een persoonlijk document hoort achter toegangsbeveiliging. Die verschillen bepalen wat je met een melding doet.
Schrijf daarom vóór het openen van een foutgroep één zin per belangrijk adres: deze pagina moet openbaar vindbaar zijn voor deze bezoeker met deze vraag. Lukt dat niet, bespreek dan eerst de bedoeling met degene die de inhoud beheert. Anders probeer je mogelijk iets te indexeren dat bewust buiten zoekresultaten blijft.
Kies de property die bij het onderzochte adres hoort
Neem de volledige URL over, inclusief protocol, host, pad en eventuele parameters. Controleer of je geselecteerde property die variant omvat. Een URL-prefixproperty voor één host en protocol vertegenwoordigt niet vanzelf andere varianten. Een domeinproperty geeft een ruimer overzicht, maar ontslaat je niet van de controle op het exacte adres.
Noteer bijvoorbeeld dat een productlink met www begint, terwijl iemand een adres zonder www heeft geïnspecteerd. Onderzoek vervolgens of beide varianten dezelfde inhoud leveren of dat een omleiding plaatsvindt. Voeg de waarnemingen pas samen wanneer je hun relatie hebt vastgesteld. Verschillende schrijfwijzen zijn geen voldoende bewijs van verschillende pagina’s.
Gebruik geen universeel gezond percentage geïndexeerde URL’s. Een webshop met veel gelijkwaardige filters kan terecht veel uitgesloten adressen hebben. Een kleine dienstensite kan met één ontbrekende kernpagina juist een belangrijk probleem hebben. Vergelijk de bedoelde canonieke inhoud met het beschikbare bewijs. Voor de bredere afweging tussen inhoud en techniek kun je verder lezen over SEO voor je website.
Maak het verschil tussen je inventaris en Google zichtbaar
Dossier Binnenlijn gaat over een volledig fictieve onderdelenwebshop. Binnenlijn is geen Niblahklant. Alle aantallen, adressen, datums en controles in dit dossier zijn oefengegevens. Er is voor dit voorbeeld niets in Search Console uitgevoerd. Je gebruikt de berekening om je eigen administratie op te zetten, niet als vergelijking met een behaald resultaat.
De eigen inventaris bevat 24 URL’s. Daarvan zijn tien publieke voorkeursadressen, zes gelijkwaardige filtervarianten, drie verhuisde adressen, drie definitief verdwenen pagina’s zonder vervanger en twee beveiligde privéadressen. De tien voorkeursadressen krijgen de codes B01 tot en met B10. De overige codes houden inhoudelijk andere bedoelingen uit elkaar.
| Groep | Eigen inventaris | Indexbewijs | Bekend niet geïndexeerd | Niet aangetroffen |
|---|---|---|---|---|
| Publieke voorkeursadressen | 10 | 6 | 2 | 2 |
| Alle overige bedoelingen | 14 | 0 | 12 | 2 |
| Totaal binnen dit dossier | 24 | 6 | 14 | 4 |
Het fictieve rapportmoment kent twintig van deze 24 adressen: zes gewenste publieke pagina’s met indexbewijs, twee gewenste publieke pagina’s zonder indexatie en twaalf overige niet geïndexeerde adressen. Vier inventarisadressen zijn niet aangetroffen. Dat zijn twee publieke voorkeursadressen en twee adressen uit de overige groepen. Hun precieze toestand blijft onbekend.
Reken met tien belangrijke adressen, niet met alles tegelijk
De relevante rekensom luidt: tien belangrijke pagina’s bestaan uit zes met indexbewijs, twee bekende niet geïndexeerde en twee onbekende. Je hebt voor zes van tien indexbewijs. Voor twee van tien ken je een afwijking. Voor twee van tien ontbreekt een waarneming. Dat laatste mag je niet stilzwijgend bij de bekende afwijkingen optellen.
De berekening zes gedeeld door twintig beschrijft iets anders: het aandeel geïndexeerde adressen binnen het bekende rapportdeel. Zes gedeeld door 24 gebruikt weer de volledige eigen inventaris. Geen van beide beantwoordt rechtstreeks hoeveel gewenste publieke pagina’s aantoonbaar geïndexeerd zijn. Schrijf daarom bij ieder getal de doelgroep en de datum.
Google kent niet noodzakelijk alles uit jouw inventaris. Andersom kan Google adressen kennen die jouw huidige overzicht mist. Een lijst met voorbeelden is bovendien geen gegarandeerd volledige populatie. Bewaar het rapportbeeld naast de export. Wordt een onbekende waarde in een export als nul weergegeven, noteer dan onbekend totdat je echte afwezigheid hebt gemeten.
Een praktische controle is de inventarisregel terugzoeken zonder meteen een oorzaak in te vullen. Ontbreekt B09 in de voorbeelden, schrijf dan niet dat B09 nooit is gevonden. Noteer uitsluitend waar je zocht, welk filter actief was en dat het adres daar niet verscheen. URL-inspectie kan daarna aanvullend bewijs geven.
Bewaar wijzigingen zonder oude waarnemingen te overschrijven
Geef iedere inventarisregel een vaste code, ook als het adres later verandert. Bewaar het oude adres en het nieuwe adres dan in afzonderlijke velden. Anders kan een latere export lijken te gaan over dezelfde pagina, terwijl je ongemerkt een andere URL vergelijkt. Voor Binnenlijn blijft B01 de inhoudelijke producttaak aanduiden; het onderzochte adres staat steeds uitgeschreven bij de meting. Voeg een korte wijzigingsreden toe wanneer de bedoeling verandert. Een pagina die van openbaar naar privé gaat, verlaat daarmee de publieke onderzoeksgroep. Dat is een beleidswijziging, geen aangetoond technisch herstel.
Lees ontwikkeling met datum, wijziging en actuele proef
Bewaar bij ieder rapportmoment de property, rapportdatum, gekozen sitemapfilter en verwachte doelgroep. Voeg het moment toe waarop de website is gewijzigd. Een stijgende lijn zonder die gegevens kan verschillende groepen door elkaar mengen. Een afname na het opruimen van oude varianten kan bijvoorbeeld passen bij je bedoeling, maar vraagt nog steeds controle.
Vergelijk twee momentopnamen alleen wanneer de noemer voldoende gelijk is. Als de eerste selectie tien productpagina’s bevat en de tweede ook informatiepagina’s, kun je de beweging niet uitsluitend aan productherstel toeschrijven. Leg gewijzigde groepsleden apart vast. Zo blijft zichtbaar of de website veranderde, de selectie veranderde of Google andere informatie rapporteerde.
B01: een nieuw rapport kan nog een oude crawl beschrijven
In een aanvullende fictieve oefening krijgt B01 op 7 oktober om 14.00 uur een technische reparatie. Het rapport draagt de datum 9 oktober, maar de bewaarde laatste crawl van B01 is van 6 oktober. De latere rapportdatum bewijst dus niet dat Google de reparatie al heeft beoordeeld.
De beheerder voert op 9 oktober een actuele proef uit en noteert tijd, adres en websiteversie. Levert B01 nu een tijdelijke 302 naar een onderhoudspagina, dan is dat de huidige bevinding. Het oude rapport kan die huidige respons niet bevestigen of ontkennen. De tijdelijke bereikbaarheid van gisteren bewijst evenmin dat vandaag alles werkt.
Stel dat dezelfde proef een 401 oplevert omdat iemand B01 achter een inlogscherm heeft gezet. Dan moet eerst worden besloten of B01 nog openbaar hoort te zijn. Is de pagina per ongeluk afgeschermd, dan onderzoekt de technisch beheerder de toegang. Is de afscherming bewust, dan verandert de indexbedoeling en daarmee de beoordeling.
De werkwijze uit Googles uitleg over URL-inspectie helpt dit onderscheid bewaken: bewaarde indexinformatie en een live test beantwoorden verschillende vragen. Een ontbrekende verwijzende pagina betekent ontbrekende informatie. Een geslaagde live test voorspelt geen canonieke keuze of opname. Een indexeringsverzoek kent beperkingen en geeft geen termijn.
Bewaar meetregels die iemand anders kan herhalen
Schrijf bij een actuele controle minimaal het volledige adres, het tijdstip, de respons en de aangetroffen inhoud op. Voeg bij een wijziging een herkenbare versieomschrijving toe, bijvoorbeeld producttemplate na herstel van de indexinstelling. Bewaar gevoelige sessiegegevens niet in een gedeeld dossier. Een collega moet de openbare controle kunnen herhalen zonder jouw persoonlijke account.
Rapportstatus is geen live HTTP-meting en geen rankingbewijs. Een geïndexeerde pagina kan een andere zoekpositie hebben dan je verwacht. Een momenteel werkende pagina kan nog ontbreken in bewaarde indexinformatie. Houd het besluit beperkt tot de vraag die je werkelijk hebt onderzocht, zodat vervolgwerk niet op een te ruime conclusie rust.
Los tegenstrijdige metingen op voordat je een taak sluit
Stel dat de productbeheerder een volledige pagina ziet, maar een anonieme controle alleen een melding krijgt. Leg beide omstandigheden vast: ingelogd of uitgelogd, volledig adres, tijdstip en ontvangen inhoud. Herhaal daarna dezelfde openbare aanvraag onder vergelijkbare omstandigheden. Verander tussendoor niet meerdere instellingen tegelijk, want dan verdwijnt het verband tussen oorzaak en uitkomst. Blijft het verschil bestaan, laat de technisch verantwoordelijke onderzoeken welke voorwaarde de respons bepaalt. De conclusie is voorlopig dat de levering verschilt. Een goed werkende beheerdersweergave weerlegt de anonieme fout niet.
Gebruik een ingevulde beslismatrix voor de tien redenen
De onderstaande matrix bevat zelfstandige oefengevallen. Het zijn mogelijke vervolgsituaties voor het dossier, geen aanvullende telling van het oorspronkelijke rapportmoment. Je mag de tien rijen dus niet optellen bij de twintig bekende adressen. Elke rij laat zien welke actuele waarneming je eerst nodig hebt voordat een label tot werk leidt.
Houd bedoeling, waarneming en hypothese in afzonderlijke velden. De bedoeling komt van jouw organisatie. Een waarneming komt uit een gedateerde controle. Een hypothese is een mogelijke verklaring die nog moet worden onderzocht. De eigenaar is degene die het besluit kan uitvoeren of laten uitvoeren, niet automatisch degene die het rapport heeft geopend.
| Reden | Bedoeling | Actuele oefenwaarneming | Hypothese | Eigenaar en actie | Hercontrole |
|---|---|---|---|---|---|
| Pagina met redirect | Opvolger openbaar | Oud adres verwijst rechtstreeks naar opvolger | Uitsluiting bron past | Webbeheerder controleert doel afzonderlijk | Doelrespons en doelinspectie dateren |
| Alternatief met canonical | Filter onder hoofdadres | Inhoud gelijkwaardig, voorkeursadres klopt | Alternatief is bewust | SEO-beheerder vergelijkt Googlewaarneming | Canonical en inhoud opnieuw vergelijken |
| Niet gevonden | Definitief verdwenen | Adres geeft nu 404 | Verwijdering werkt | Contentbeheerder ruimt actuele verwijzingen op | Sitemap en links nalopen |
| Gecrawld, niet geïndexeerd | Publiek product | Pagina toont alleen algemene categoriegegevens | Productinhoud ontbreekt mogelijk | Productbeheerder controleert inhoudslevering | Geleverde productinformatie vastleggen |
| Andere canonical gekozen | Eigen productadres leidend | Tag en interne links wijzen uiteen | Signalen zijn tegenstrijdig | SEO-beheerder vergelijkt drie adressen | Nieuwe indexwaarneming apart bewaren |
| Uitgesloten door noindex | Openbare handleiding | HTTP-header bevat ongewenste noindex | Templateconfiguratie is verkeerd | Ontwikkelaar herstelt bewezen instelling | Header en HTML controleren |
| Geblokkeerd door robots | Publieke categorie | Pad valt onder bestaande blokkaderegel | Regel is te ruim | Technisch beheerder beperkt relevante regel | Host en pad opnieuw toetsen |
| Andere 4xx | Openbaar onderdeel | Anonieme aanvraag krijgt 403 | Toegangsregel weigert verzoek | Hostingbeheerder onderzoekt toegangsvoorwaarde | Anonieme herhaling na wijziging |
| Gevonden, niet geïndexeerd | Nieuwe publieke uitleg | Interne link en bereikbaarheid werken nu | Oorzaak blijft onbekend | SEO-beheerder bewaart beschikbaarheidsgegevens | Nieuwe crawlwaarneming vergelijken |
| Redirectfout | Oud adres naar vervanger | Twee adressen verwijzen naar elkaar | Regels veroorzaken lus | Ontwikkelaar corrigeert vastgestelde route | Volledige requestreeks herhalen |
Geef iedere rij daarnaast een eigen hercontroledatum. Kies die als werkafspraak op basis van urgentie en beschikbare mensen, niet als voorspelling van Googles verwerking. Een privacylek vraagt directe bronactie. Een onbekende status van een secundaire filtervariant kan later worden onderzocht. Een belangrijke onbereikbare productpagina verdient eerder technische aandacht.
De uitkomsten van dit werkblad zijn concreet: bewust laten staan, toegang herstellen, inhoud onderzoeken, signalen uitlijnen of meer bewijs verzamelen. Het werkblad kan geen indexatie toezeggen. Voor meerdere samenhangende afwijkingen kan een SEO-audit helpen de onderzoeksvragen en verantwoordelijkheden af te bakenen.
Koppel prioriteit aan bezoekerstaak en risico
Zet bij elke open rij wat een bezoeker nu niet kan doen. Bij een onbereikbaar onderdeel kan dat het controleren van geschiktheid zijn. Bij een ontbrekende handleiding kan het gaan om veilig gebruik van een al gekocht product. Bij een gelijkwaardige sorteervariant ontbreekt mogelijk helemaal geen zelfstandige taak. Zo krijgt het dossier een werkvolgorde zonder onbewezen verkeersverlies te berekenen. Voeg daarnaast toe of de voorgestelde ingreep andere adressen kan raken. Een brede templatewijziging vraagt een ruimere controle dan het herstellen van één verkeerd geschreven interne link.
Beoordeel verhuisde en verdwenen adressen afzonderlijk
Een correcte redirect vraagt nog een controle van het doel
Bij een echte verhuizing is het oude adres normaal niet meer het indexdoel. Begin met de inhoudelijke vraag: is de bestemming de bedoelde opvolger? Controleer daarna welke respons het oude adres werkelijk geeft en waar je eindigt. Inspecteer het eindadres afzonderlijk, ook wanneer de omleiding in je browser netjes lijkt te werken.
Binnenlijn heeft drie verhuisde adressen in de inventaris. Voor één oefengeval vervangt een nieuwe maatvoering een oud product. De productbeheerder moet bevestigen of het nieuwe onderdeel daadwerkelijk dezelfde bezoeker helpt. Een technisch werkende verwijzing naar een willekeurig product is geen voldoende onderbouwing voor de gekozen bestemming.
Leg bij het eindadres de bereikbaarheid, geleverde inhoud, indexinstelling en bedoelde canonical vast. Een redirect kan immers eindigen op een afgeschermde pagina of een pagina met noindex. Het bronadres en het doel krijgen daarom elk een eigen bewijsregel. De werking van de eerste regel bewijst niets over de tweede.
Onderhoud oude en nieuwe adressen overzichtelijk met een redirectlijst. Zet daarin ook de reden voor de verhuizing en wie de bestemming heeft goedgekeurd. Dan kan een latere beheerder beoordelen of de relatie nog klopt wanneer het assortiment opnieuw verandert.
Een bedoelde 404 hoeft niet te worden gerepareerd
Voor drie Binnenlijnpagina’s bestaat geen vervanger. Als de inhoud definitief weg is, kan een 404 passen bij die bedoeling. Controleer de actuele respons voordat je dat vastlegt. Een historische Googlemelding vertelt wat eerder is waargenomen, niet wat het adres op dit moment terugstuurt.
Beoordeel verwijzingen afzonderlijk. Staat de verdwenen pagina nog in je huidige sitemap of in een koopadvies, dan kun je die verwijzing verwijderen of inhoudelijk aanpassen. Bestaat een nuttig publiek alternatief, beoordeel dan of een verwijzing de bezoeker helpt. Stuur niet automatisch alle verdwenen adressen naar de homepage.
Een foutpagina die visueel meldt dat iets ontbreekt maar technisch gewone inhoud lijkt te leveren, vraagt een andere controle. Bekijk dan de combinatie van status en pagina-inhoud. De uitleg over soft 404’s opsporen en oplossen helpt bij het afbakenen van dat onderzoek.
Schrijf bij een omleidingsfout elke stap uit
Begin bij exact het gemelde adres. Noteer per aanvraag de respons en het volgende adres. Zo onderscheid je een verkeerd gespelde bestemming, een lus, meerdere opeenvolgende omleidingen en een eindpagina met een toegangsprobleem. Gebruik geen vaste ketenlimiet als vervanging voor deze diagnose.
In een oefening verwijst oud onderdeel A naar nieuw onderdeel B, terwijl een tweede regel B terugstuurt naar A. Dat is een aantoonbare lus. De ontwikkelaar past de veroorzakende regel aan en herhaalt dezelfde beginvraag. Controleer ook een gerelateerd adres dat goed werkte, zodat een brede regelwijziging niet ongemerkt een andere route beschadigt.
Neem bij de requestreeks ook parameters mee. Een oud adres kan zonder parameter goed eindigen, terwijl een gedeelde variant met een maatselectie op een verkeerd product uitkomt. Laat de productbeheerder bepalen of die selectie behouden moet blijven. Controleer vervolgens precies die afgesproken variant. Schrijf niet dat alle redirects zijn hersteld wanneer je alleen het kale adres hebt getest. Het eindcriterium kan bijvoorbeeld zijn dat beide afgesproken beginadressen rechtstreeks bij de inhoudelijk juiste opvolger uitkomen. Bewaar overige varianten als onbekend totdat ze zelf zijn gecontroleerd.
Vergelijk canonicals met inhoud en drie concrete adressen
Laat een gelijkwaardig alternatief staan als de keuze klopt
Een alternatieve pagina met een correcte canonical hoeft geen fout te zijn. Binnenlijn heeft zes gelijkwaardige filtervarianten. Bij zo’n variant vergelijk je de producten, de gebruikersvraag en de bedoelde voorkeursinhoud. Controleer vervolgens of de opgegeven canonical daar daadwerkelijk naartoe wijst en wat Google in de bewaarde inspectie als voorkeur toont.
Neem een sorteervariant die precies dezelfde onderdelen van goedkoop naar duur toont. Als de zelfstandige inhoud gelijkwaardig blijft en het hoofdadres de gewenste ingang is, kan uitsluiting van die variant passen. Documenteer die keuze. Alleen het bestaan van een melding rechtvaardigt geen wijziging aan alle filterpagina’s.
Onderzoek het geïnspecteerde adres, jouw voorkeur en Googles keuze
Wanneer Google een andere canonical kiest, leg je drie adressen naast elkaar: de geïnspecteerde URL, jouw opgegeven voorkeursadres en het door Google gekozen adres. Noteer voor elk de datum, respons, inhoud, canonical en relevante interne verwijzingen. Twee van die adressen kunnen gelijk zijn; ook dat hoort expliciet in het dossier.
Stel dat een parameterpagina alleen onderdelen voor buitengebruik bevat, met eigen specificaties en een afzonderlijke keuzehulp. Een andere parameterpagina bevat binnenonderdelen. Dan is gelijkwaardigheid geen veilige aanname. De oorspronkelijke zes gelijkwaardige varianten uit Binnenlijn veranderen hierdoor niet; dit is een aparte beslisoefening voor een toekomstige uitbreiding.
De productbeheerder vergelijkt materiaal, toepassing en assortiment. De SEO-beheerder onderzoekt welk adres interne links en sitemap noemen. De ontwikkelaar controleert de daadwerkelijk geleverde tags. Pas daarna kiezen zij of samenvoegen logisch is of dat iedere pagina een eigen publieke taak heeft. Een parameter op zichzelf beslist die vraag niet.
Een eigen canonical is een voorkeurssignaal, geen garantie dat Google hetzelfde adres kiest. Een live test kan de huidige technische situatie helpen beoordelen, maar voorspelt die keuze niet. Bewaar daarom na een aanpassing de nieuwe technische controle naast een latere indexwaarneming, zonder beide als hetzelfde bewijs te presenteren.
Gebruik noindex niet gedachteloos als extra canonicalinstructie. Eerst moet duidelijk zijn of je een pagina wilt uitsluiten of gelijkwaardige inhoud wilt laten samenbrengen. De afweging staat verder uitgewerkt bij noindex en canonical tegelijkertijd gebruiken.
Maak de inhoudsvergelijking tastbaar door per adres dezelfde drie vragen te beantwoorden: welk onderdeel wordt aangeboden, voor welke toepassing en met welke beperkingen? Schrijf concrete verschillen op in plaats van alleen uniek of dubbel. Twee pagina’s met andere titels kunnen dezelfde productset en keuzehulp tonen. Twee vergelijkbaar vormgegeven pagina’s kunnen juist wezenlijk andere toepassingen uitleggen. De vorm van het adres en de lengte van de tekst zijn daarom geen zelfstandig besliscriterium. Laat de uiteindelijke voorkeur aansluiten bij de inhoudelijke taak die je voor deze pagina hebt vastgelegd.
Scheid indexinstellingen, crawlblokkades en toegangsbeveiliging
Controleer noindex in de werkelijk geleverde pagina
Vraag eerst of uitsluiting de bedoeling is. Een openbare handleiding met een onbedoelde noindex vraagt herstel. Een bevestigingspagina die bewust niet in zoekresultaten hoeft, vraagt mogelijk helemaal geen aanpassing. Controleer zowel de relevante HTTP-header als de HTML-meta-instructie; alleen een instelling in het beheerscherm bekijken is onvoldoende.
In de matrix staat een handleiding waarbij een header de uitsluiting veroorzaakt. De ontwikkelaar onderzoekt waar die header wordt toegevoegd: bij de toepassing, een template of een andere beheerlaag. Vervolgens wijzigt diegene uitsluitend de vastgestelde oorzaak. De hercontrole bekijkt opnieuw de echte respons en de HTML, inclusief mogelijke tegenstrijdige instructies.
Bij een WordPress- of Shopifywebsite kan een centrale wijziging meerdere pagina’s raken. Kies daarom vooraf een tweede pagina met een andere bedoeling als controle. Een openbare handleiding moet na herstel geen onbedoelde uitsluiting bevatten, terwijl een bewust uitgesloten hulppagina zijn gekozen instelling moet behouden. Zo controleer je ook de begrenzing van het herstel.
Onderzoek robots.txt op de juiste host en het juiste pad
Een robots.txt-regel beperkt crawlen. Zo’n regel is geen toegangsbeveiliging en biedt geen garantie dat een URL buiten de index blijft. Als Google een noindex moet lezen, moet de betreffende inhoud bereikbaar zijn voor die controle. Wis daarom niet blind alle blokkades om één melding te laten verdwijnen.
Schrijf de betrokken host, het pad en de toepasselijke regel op. Vergelijk een getroffen publieke categorie met een pad dat bewust geblokkeerd hoort te blijven. Maak de regel alleen smaller als de diagnose laat zien dat de huidige afbakening verkeerd is. Controleer daarna de actuele robotsrespons en beide paden opnieuw.
Behandel een 401 of 403 als een eigen toegangsvraag
Een 401 kan passen bij vereiste authenticatie. Een 403 vraagt onderzoek naar de voorwaarden waaronder toegang wordt geweigerd. Andere 4xx-responses kunnen weer een andere aanleiding hebben. Begin daarom met een anonieme aanvraag en de exacte respons, in plaats van iedere melding aan dezelfde cache of plugin toe te schrijven.
De twee privéadressen van Binnenlijn horen beschermd te blijven. Controleer daar of iemand zonder account de inhoud werkelijk niet ontvangt. Voor een publiek product is dezelfde afscherming mogelijk onbedoeld. Laat de verantwoordelijke beheerder de concrete toegangsregel onderzoeken. Een algemene cache-reset is zonder bewijs geen gerichte oplossing voor een autorisatieprobleem.
Noteer ook of de fout alleen onder bepaalde omstandigheden optreedt. Een ingelogde beheerder kan immers iets anders zien dan een anonieme bezoeker. Laat technische controles uitvoeren zonder beveiliging breed uit te schakelen. Bij samenhangende instellingen helpt een afgebakend onderzoek naar technische SEO om de verantwoordelijke laag te vinden.
Gebruik bij een toegangsreparatie een kleine controlegroep met tegengestelde bedoelingen. Kies één getroffen openbare pagina, één openbare pagina die al werkte en één bewust beschermd adres. Schrijf vooraf op welke uitkomst ieder adres moet geven. Controleer na de wijziging dezelfde drie gevallen. Krijgt het beschermde adres plots openbare inhoud, dan is de reparatie te breed, ook als de productpagina weer opent. Herstel eerst die onbedoelde toegang en onderzoek daarna een smallere oplossing. Neem nooit echte vertrouwelijke documenten over in screenshots die je buiten het bevoegde team deelt.
Onderzoek gevonden en gecrawlde pagina’s zonder oorzaken te verzinnen
Gecrawld maar niet geïndexeerd: vergelijk wat werkelijk is geleverd
Dit label beschrijft een waarneming. Het bewijst geen wachtrij en geen kwaliteitsstraf. Begin bij de inhoud die op de onderzochte URL daadwerkelijk wordt geleverd. Komt het product overeen met de titel? Zijn de specifieke eigenschappen aanwezig? Lijkt de pagina inhoudelijk op een andere URL die dezelfde bezoekerstaak al vervult?
In de oefenmatrix levert een productadres alleen algemene categoriegegevens. De productbeheerder vergelijkt de bedoelde producttekst met de zichtbare pagina. De ontwikkelaar onderzoekt of de gegevens ontbreken in de bron, verkeerd worden gekoppeld of niet worden weergegeven. Dat zijn toetsbare mogelijkheden. De rapportstatus vertelt niet welke ervan de verklaring is.
Vul daarna een concrete inhoudelijke taak in. Een onderdeelpagina moet bijvoorbeeld aangeven voor welke aansluiting het onderdeel geschikt is. Als juist die informatie ontbreekt, is aanvullen zinvol voor de bezoeker. Schrijf niet willekeurig extra alinea’s om een onbekend indexatieprobleem met tekstlengte te behandelen. De ontbrekende taak bepaalt welke verbetering relevant is.
Gevonden maar niet geïndexeerd: controleer de route naar de pagina
In de bewaarde observatie is het adres bekend, zonder bijbehorende crawl. Daaruit volgt geen bewezen oorzaak rond kwaliteit, capaciteit of wachtrijen. Controleer de huidige interne verwijzing, sitemapvermelding, HTTP-respons en beschikbare gegevens over bereikbaarheid. Een vastgesteld crawlbudgetprobleem vereist meer onderbouwing dan dit label alleen.
Binnenlijn kan voor B09 bijvoorbeeld vastleggen dat de productpagina nu vanuit een categorie bereikbaar is. Open de categorie anoniem en controleer de echte linkbestemming. Een klikbaar element dat alleen een filter opent is niet hetzelfde als een gewone verwijzing naar B09. Noteer het gevonden adres voordat je conclusies trekt.
Een leeg verwijzend veld vraagt een zelfstandige linkproef
Een ontbrekende verwijzende pagina is onbekende rapportinformatie. Het bewijst niet dat er geen links bestaan en verklaart niet waarom indexatie ontbreekt. Zoek daarom zelf een relevante bronpagina, controleer de echte href en vraag de bestemming op. Bewaar bron, doel, respons en tijdstip als een zelfstandige waarneming.
De conclusie mag dan luiden dat deze verwijzing op dat moment aanwezig was en werkte. Je hebt daarmee niet aangetoond dat Google haar heeft gevolgd of dat alle andere verwijzingen ontbreken. De uitleg over interne links helpt om zulke verbindingen vanuit de bezoekerstaak te beoordelen.
De afbakening van rapportredenen, voorbeelden en herstelcontroles staat in Googles documentatie over Pagina-indexering. Gebruik die beschrijvingen om labels te begrijpen. Maak de oorzaak in jouw dossier pas definitief wanneer je eigen controle de veronderstelling ondersteunt.
Controleer het bestaande sitemapbestand voordat je het indient
Een sitemap begint op je eigen website. Bepaal welk bestaand bestand de bedoelde publieke voorkeursadressen bevat. Open het volledige sitemapadres en controleer of je werkelijk het juiste XML-bestand ontvangt. Een foutpagina, inlogscherm of ander document op hetzelfde adres is geen bruikbare vervanging, ook wanneer de URL geloofwaardig klinkt.
Laat een property-eigenaar het bestaande bestand controleren. Open daarna Sitemaps in de juiste property, plak het gecontroleerde volledige sitemapadres in het invoerveld en klik op Indienen. Bekijk de gemelde verwerking. Controleer eerst of het bestand al vermeld staat. Een robots.txt-verwijzing is een andere aanmeldroute; beide routes gebruiken garandeert geen snellere indexering.
Leg de huidige XML en de laatste leesdatum apart vast
Bij Binnenlijn bevat een oefensitemap precies de tien publieke voorkeursadressen. De beheerder bewaart de bestandsversie en het controletijdstip. Daarnaast noteert diegene de laatste leesdatum uit het rapport. Is die leesdatum ouder dan de aanpassing, dan mag de huidige inhoud niet worden behandeld alsof Google haar al heeft ingelezen.
Controleer bij een mislukte verwerking eerst het exacte bestand en de gerapporteerde fout. Onderscheid ophalen van het bestand van het kunnen verwerken van de XML. Vergelijk ook of je dezelfde host en hetzelfde pad onderzoekt. Een technisch werkend ander sitemapbestand verklaart niet automatisch waarom het gemelde bestand eerder niet werkte.
Volgens Googles uitleg over het Sitemaps-rapport betekent succes dat de sitemap kon worden verwerkt. Ontdekte pagina’s zijn de unieke pagina-adressen die daaruit zijn gelezen, geen telling van gecrawlde of geïndexeerde pagina’s. Verwijderen uit het rapport wist Googles kennis van de adressen niet.
De verdere inrichting kun je afbakenen met de uitleg over een XML-sitemap maken en instellen. In dit dossier blijft de controle beperkt tot het bestaande bestand, de bedoelde inhoud en de relatie met je indexonderzoek. Een indiening wordt hier niet uitgevoerd.
Een bruikbare sitemapcontrole begint bij adressen, niet bij aantallen. Koppel iedere vermelding aan een regel in de inventaris en markeer adressen waarvoor nog geen bedoeling is vastgelegd. Controleer steekproeven alleen als steekproeven: benoem hoeveel adressen je werkelijk hebt bekeken. Als tien adressen worden verwacht en je drie hebt geopend, zijn zeven actuele reacties nog onbekend. Je kunt vervolgens gericht verder controleren. Vermijd een algemene goedkeuring van het bestand op basis van één werkend voorbeeld. Het bestand kan correct worden verwerkt terwijl afzonderlijke bestemmingen nog onderzoek vragen.
Gebruik een sitemapfilter met een duidelijke doelgroep
De tien publieke Binnenlijnadressen vormen een nuttige onderzoeksgroep. Een sitemapfilter kan helpen die groep in het rapport terug te vinden. Controleer wel de daadwerkelijke selectie: een bestand kan nog oude of onbedoelde URL’s bevatten. Alleen het bestaan van een sitemap voorkomt geen ruis in je beoordeling.
Splits de groep voor het werk bijvoorbeeld in zes productpagina’s en vier handleidingen. Dit is een eigen inhoudelijke indeling binnen de tien voorkeursadressen. De oorspronkelijke verdeling van indexbewijs blijft ongewijzigd zolang je geen aanvullende gegevens hebt. Verdeel de zes geïndexeerde pagina’s dus niet op gevoel over beide subgroepen.
Vergelijk subgroepen onder dezelfde omstandigheden
Leg voor producten en handleidingen dezelfde rapportdatum, property en filtergrondslag vast. Noteer hoeveel bedoelde adressen je per subgroep verwacht. Verandert de sitemap tussendoor, bewaar dan welke leden op welk moment werden geselecteerd. Anders kan een schijnbare verbetering ontstaan doordat een lastig adres uit de meetgroep verdween.
Stel dat de sitemap tien adressen meldt en het indexrapport voor je selectie acht bekende adressen toont. Dat verschil bewijst geen noindexprobleem of duplicatie. Begin met het koppelen van de concrete URL’s. Zoek vervolgens welke adressen ontbreken en welke gegevens onbekend zijn. Pas inspectie kan de aanleiding voor een specifieke afwijking verduidelijken.
Haal een verouderde sitemap niet alleen uit het rapport
Een oude sitemap uit het rapport verwijderen verandert de bron niet. Onderzoek daarom of het bestand nog bereikbaar is, elders wordt genoemd of nog verkeerde adressen bevat. Pas de echte sitemap en actuele interne verwijzingen aan wanneer de bedoeling is veranderd. Beoordeel de betrokken URL’s vervolgens volgens hun eigen bestemming.
Bewaar bij bewust behouden oude adressen waarom ze blijven bestaan. Een oude producthandleiding kan bijvoorbeeld nog nodig zijn voor bestaande gebruikers, ook als zij niet meer actief wordt aangeboden. De keuze voor openbaar bewaren, omleiden of verwijderen ligt bij de inhoudelijke eigenaar. Het opschonen van een rapport beslist dat niet.
Kies tussen een indexeringsaanvraag en herstelvalidatie
Vraag indexering pas na een concrete controle aan
Een nieuwe belangrijke pagina of een aantoonbaar herstelde URL kan aanleiding zijn om indexering aan te vragen. Inspecteer eerst het volledige juiste adres. Bevestig dat de huidige pagina de bedoelde inhoud levert en dat de geconstateerde blokkade werkelijk is opgelost. Een aanvraag is geen vervanging voor die technische controle.
Noteer welk adres je hebt aangevraagd, wanneer en vanwege welke wijziging. Aanvragen kennen dagelijkse beperkingen; ga niet uit van een vast aantal of een vast resetuur. Herhaald aanvragen geeft geen versnellingsbelofte. Plan je eigen hercontrole als werkafspraak en houd de uitkomst open totdat nieuwe informatie beschikbaar is.
Valideer een herstelde reden binnen een bewezen groep
Herstelvalidatie gaat over een specifieke reden en de daarbij bekende gevallen binnen de gekozen scope. Een sitemapfilter kan die scope begrenzen. Dit is iets anders dan één URL voor indexering aanbieden. Bewijs daarom vóór de start welke groep je hebt hersteld en welk criterium voor ieder groepslid geldt.
Gebruik een afzonderlijke fictieve oefening met vijf handleidingen die allemaal onbedoeld noindex kregen. Deze groep hoort niet bij de telling van het eerdere Binnenlijnrapport. De ontwikkelaar controleert na herstel op alle vijf adressen de relevante headers en HTML. De eigenaar bewaart het overzicht en start pas daarna de passende validatie.
Blijkt één handleiding nog bewust afgeschermd, dan moet die bedoeling eerst worden vastgelegd. Je kunt een inhoudelijk andere toestand niet als opgelost behandelen alleen omdat zij in dezelfde oorspronkelijke foutgroep stond. Het herstelcriterium blijft per adres toetsbaar: de gewenste openbare handleiding levert de bedoelde inhoud zonder de onbedoelde uitsluitingsinstructie.
Lees processtatus en indexbewijs in aparte kolommen
Not started betekent dat minstens één geval nooit in een validatie voor deze reden is opgenomen. Started is gestart; Looking good is een gunstige tussenstand. Passed meldt afgehandelde bekende gevallen, Failed een aangetroffen resterend probleem. N/A betekent dat Google het herstel zonder aangevraagde validatie vaststelde. Bij een afzonderlijk geval kan Other betekenen dat de URL niet meer bereikbaar is; dat telt als afgehandeld voor deze reden, zonder indexbewijs. Wacht een lopende cyclus af. Onderzoek bij Failed het gemelde geval voordat je nieuwe validatie start. Afhandeling van één reden bewijst geen herstel van andere problemen.
Stel dat het oefenoverzicht enkele gevallen als Passing toont, één als Other en voor een restant geen bruikbare detailinformatie geeft. Dan zijn er gunstige deelwaarnemingen, een apart te beoordelen geval en onbekende gegevens. Maak daar geen volledige succesmelding van. De beheerder bewaart precies welke adressen bij welke waarneming horen.
Na Passed blijft de eigen vraag bestaan of de gewenste pagina daadwerkelijk geïndexeerd is. Vul daarvoor een afzonderlijke kolom met een gedateerde inspectiewaarneming. Zo kan een technische reparatie klaar zijn terwijl je het indexonderzoek nog niet sluit. Dat onderscheid maakt de overdracht tussen ontwikkelaar en SEO-beheerder duidelijk.
Maak bij een mislukte validatie een nieuwe bewijsregel in plaats van de vorige te wissen. Noteer welk adres opnieuw is gemeld en controleer of hetzelfde probleem nu werkelijk aanwezig is. Vergelijk daarna de gecontroleerde versie met de eerder herstelde versie. Mogelijk is een instelling teruggezet of valt het adres onder een andere template. Dat zijn onderzoeksvragen, geen vaststaande verklaringen. Als de actuele proef het probleem niet laat zien, behoud je beide waarnemingen met hun datums. Plan gericht vervolgonderzoek naar het verschil voordat iemand dezelfde reparatie nogmaals uitvoert.
Gebruik Verwijderingen alleen voor een passende verwijdervraag
Begrens een tijdelijk verzoek voordat je het verstuurt
Tijdelijke verwijdering is bedoeld voor een noodzakelijke verberging van zoekresultaten binnen je eigen property. De werking duurt ongeveer zes maanden. Het is geen opruimer voor indexmeldingen en geen middel om een canonical te kiezen. Regel daarnaast wat er met de bron moet gebeuren, zeker wanneer informatie niet openbaar hoort te zijn.
Maak vóór een verzoek een concrete lijst van adressen die wel en niet geraakt mogen worden. Bij Binnenlijn zou de prefix /werk onbedoeld zowel /werk/ als /werkplaats/ kunnen omvatten. Een nauwkeuriger prefix /werk/ heeft een andere begrenzing. Test je selectie op echte voorbeeldadressen uit de inventaris voordat je tussen één URL en een prefix kiest.
Laat de inhoudelijke eigenaar die begrenzing bevestigen. Noteer de gekozen property, het exacte doel en uitgesloten buuradressen. Een te ruime selectie kan ook nuttige openbare pagina’s raken. Een te smalle selectie kan een tweede openbare variant laten staan. Gebruik geen persoonsgegevens om die oefenlijst te verduidelijken.
Maak privé-inhoud werkelijk ontoegankelijk
Een permanent gewenste verwijdering vraagt een blijvende bronactie. Beveilig privé-inhoud met passende toegang of verwijder informatie die niet meer beschikbaar hoort te zijn. Noindex is geen beveiliging. Robots.txt is geen verwijderingsgarantie. Controleer na de ingreep met een echte anonieme aanvraag of de inhoud nog bereikbaar is.
Vergeet bestanden niet. Een document kan uit een pagina zijn gehaald terwijl de openbare PDF nog op een bekend adres staat. Controleer ook oude bestandsvarianten en rechtstreeks gedeelde adressen. Leg uitsluitend vast of de toegang is gesloten; kopieer de gevoelige inhoud niet naar een algemeen SEO-werkblad.
Een verwijderverzoek, het vernieuwen van een verouderde snippet en het aanpassen van broninhoud hebben verschillende gevolgen. Bepaal of je het zoekresultaat tijdelijk wilt verbergen, de getoonde beschrijving wilt laten actualiseren of de informatie werkelijk onbeschikbaar wilt maken. Kies de handeling op basis van dat doel.
Gebruik verouderde content bij een veranderde of verdwenen bron
De tool voor verouderde content past bij een bron die werkelijk is gewijzigd of verdwenen terwijl Google nog een verouderd beeld toont. Ook iemand zonder eigenaarschap kan daarvoor een verzoek doen. De bijbehorende Search Console-tab toont verzoekgeschiedenis; zij is geen algemene functie om willekeurige inhoud overal te wissen.
Behandel SafeSearch als classificatievraag
SafeSearch gaat over classificatie van volwassen inhoud voor gebruikers met dat filter. Het is geen algemene reparatie voor indexatie. Beoordeel de gemelde status samen met de werkelijke pagina-inhoud en context. Als bezwaar mogelijk en passend is, onderbouw het daarmee. Een melding rechtvaardigt niet automatisch een verwijdering of andere ingreep.
Googles documentatie over Verwijderingen beschrijft deze afzonderlijke toepassingen. Maak in je eigen dossier vooral duidelijk welk probleem je wilt oplossen, wie bevoegd is om de bron te wijzigen en welke anonieme controle moet aantonen dat de gekozen bescherming werkt.
Beantwoord de laatste vragen en draag een concreet dossier over
Hoeveel niet geïndexeerde pagina’s zijn normaal?
Daarvoor bestaat geen bruikbaar universeel percentage. Vergelijk gewenste publieke voorkeursadressen met hun bewijs. Bewust uitgesloten filters, verhuisde adressen en beveiligde pagina’s hebben andere doelen. Houd onbekende adressen apart, zodat je geen ontbrekende waarnemingen als vastgestelde fouten telt.
Hoe snel werkt een indexeringsaanvraag?
Een aanvraag geeft geen gegarandeerde termijn of opname. Controleer eerst de concrete wijziging en vraag het juiste volledige adres aan. Herhaald aanvragen is geen betrouwbare versneller. Kies een eigen controlemoment en vergelijk dan nieuwe gegevens met je bewaarde uitgangssituatie.
Wat is het verschil tussen gevonden en gecrawld?
Gevonden beschrijft een bekend adres zonder crawl in de bewaarde observatie. Gecrawld beschrijft dat Google de pagina heeft opgehaald, terwijl opname ontbreekt. Geen van beide labels bewijst zelfstandig een oorzaak. Onderzoek actuele bereikbaarheid, inhoud en verwijzingen voordat je herstel kiest.
Betekent sitemapstatus Succes dat mijn pagina’s geïndexeerd zijn?
Nee. Succes gaat over de verwerking van het sitemapbestand. Ontdekte pagina’s zijn gelezen unieke adressen. Vergelijk de laatste leesdatum met de huidige XML en onderzoek de bedoelde pagina’s afzonderlijk. Een verschil tussen aantallen verklaart nog niet waarom een bepaalde pagina ontbreekt.
Is geslaagde validatie hetzelfde als geslaagde indexering?
Nee. Validatie beoordeelt de geselecteerde reden binnen de gecontroleerde groep. Indexbewijs vraagt een afzonderlijke waarneming per gewenste pagina. Noteer daarom zowel de herstelstatus als de indexstatus, inclusief datum en onbekende gegevens. Een technische taak kan klaar zijn terwijl indexonderzoek doorloopt.
Is een verwijderverzoek voldoende voor een privédocument?
Nee. Zorg eerst voor passende bronbescherming of verwijdering en controleer de toegang anoniem. Een tijdelijk verborgen zoekresultaat maakt een openbaar document niet privé. Onderzoek ook rechtstreeks bereikbare PDF’s en andere varianten. Deel geen gevoelige inhoud, wachtwoorden of toegangstokens in je dossier.
Controleer of een collega je besluit kan volgen
Laat een collega één dossierregel lezen. Die moet adres, actueel bewijs, voorlopig oordeel en hercontrole aanwijzen. Bewaar bij schermafbeeldingen ook property en filter in tekst. Vul ontbrekende datums, eigenaars en criteria vóór overdracht aan. Zo blijft een bewuste uitzondering herkenbaar.
Geef iedere open regel een eigenaar en een eindcriterium
Een bruikbare overdracht bevat geen opdracht als los indexatie op. Schrijf welke URL afwijkt, wat de bedoeling is, welke waarneming je hebt gedaan en welk bewijs nog ontbreekt. Wijs daarna iemand aan die de betreffende inhoud, techniek of toegang kan veranderen. De SEO-beheerder bewaakt het onderscheid tussen herstel en Googlewaarneming.
Gebruik voor B01 bijvoorbeeld als technisch eindcriterium dat de openbare productinhoud anoniem bereikbaar is zonder de vastgestelde ongewenste blokkade. Plan een eigen hercontroledatum voor die wijziging. Houd daarnaast een afzonderlijk controlemoment voor nieuwe inspectiegegevens. Sluit het dossier niet uitsluitend omdat een rapportregel van naam is veranderd.
Bewaar bij afgeronde taken ook waarom je niets hebt gewijzigd. Een correcte filtervariant kan bijvoorbeeld bewust buiten de index blijven. Dat besluit hoort naast de meetgegevens, met de naam van de verantwoordelijke. Zo blijft bij een volgende beoordeling zichtbaar dat deze toestand onderzocht en aanvaard is binnen de afgesproken bedoeling.
Niblah biedt webdesign, WordPress, Shopify en SEO. Wil je een concrete afwijking laten beoordelen, stuur dan via het Niblah-contactformulier de openbare URL, de bedoelde indexstatus, de rapportdatum en de relevante melding. Voeg je actuele controle en gewenste vervolgvraag toe. Laat wachtwoorden, tokens en persoonsgegevens weg.