AMP-statusrapport

Met dit rapport kun je fouten oplossen die ervoor zorgen dat je AMP-pagina's niet worden weergegeven in Google-zoekresultaten met AMP-specifieke functies.

In de weergave op het hoogste niveau zie je kritieke problemen die invloed hebben op AMP-pagina's op je site. Klik op een specifiek probleem om door dit probleem getroffen pagina's en details van het probleem te bekijken.

AMP-RAPPORT OPENEN

 

AMP-statusrapport in Search Console - Google Search Console-training

 

Wat er in het rapport staat

Kritieke problemen: Pagina's met kritieke AMP-problemen kunnen niet worden weergegeven op Google. Een lijst met kritieke problemen op je site wordt direct onder het diagram op de pagina op het hoogste niveau van het AMP-rapport weergegeven, met de titel Waarom AMP-pagina's ongeldig zijn. Klik op een probleem in de lijst om pagina's met het geselecteerde probleem te bekijken.

Niet-kritieke problemen (waarschuwingen): AMP-pagina's met niet-kritieke problemen kunnen nog steeds worden weergegeven op Google als er daarnaast geen kritieke problemen zijn. Een lijst met niet-kritieke problemen op je site wordt weergegeven onder de lijst met kritieke problemen op de pagina op het hoogste niveau van het AMP-rapport, met de titel Niet-kritieke problemen. Klik op een probleem in de lijst om pagina's met het geselecteerde probleem te bekijken. AMP-pagina's met waarschuwingen worden mogelijk niet weergegeven met alle mogelijke AMP-functies (zoals weergave in een carrousel met voorpaginanieuws). Met andere woorden: deze pagina's worden mogelijk alleen weergegeven als normale zoekresultaten met blauwe links.

Paginastatus (geldige en ongeldige pagina's): AMP-pagina's zijn geldig of ongeldig. Geldige AMP-pagina's kunnen worden weergegeven op Google. Ongeldige AMP-pagina's kunnen niet worden weergegeven op Google. Als een pagina kritieke problemen heeft, wordt deze als ongeldig beschouwd. Als de pagina alleen waarschuwingen of helemaal geen problemen bevat, wordt deze als geldig beschouwd. Je kunt een lijst met geldige AMP-pagina's bekijken door op Gegevens over geldige AMP-pagina's bekijken te klikken onder het diagram op de pagina op het hoogste niveau van het AMP-rapport.

Waar je op moet letten

Houd de volgende aantallen aan voor je rapport:

• 0 kritieke problemen op je site. Zie Problemen prioriteit geven en oplossen voor aanbevelingen om fouten op te lossen.
• Het totale aantal AMP-pagina's in het rapport (geldige pagina's + ongeldige pagina's) moet in de buurt komen van het aantal AMP-pagina's op je site. Als dit niet zo is, bekijk je Problemen met ontbrekende AMP-pagina's oplossen.

De lijst met getroffen URL's is slechts een sample. We kunnen niet garanderen dat de lijst elke URL bevat die door een bepaald probleem wordt beïnvloed. Het rapport is beperkt tot 1000 URL's per probleem. Het is daarnaast ook mogelijk dat er pagina's zijn die we om bepaalde redenen niet hebben waargenomen of meegeteld.

Er kunnen in totaal slechts 200 kritieke + niet-kritieke problemen in het rapport worden getoond. Als je site een lange lijst met problemen heeft (ongeacht of er actieve instanties zijn), worden alleen de 200 belangrijkste problemen getoond, gerangschikt op relevantie.

Problemen met AMP

Naast de standaard AMP-specifieke fouten kunnen de volgende aanvullende problemen (fouten en waarschuwingen) worden weergegeven in het rapport.

Google-specifieke AMP-problemen

Probleem	Beschrijving
Content komt niet overeen: ingesloten video ontbreekt	De canonieke webpagina bevat een ingesloten video die ontbreekt in de AMP-versie. Het is meestal het beste om dezelfde belangrijke contentbronnen in je AMP-versie op te nemen als op de canonieke webpagina. Houd er rekening mee dat de video wordt gedetecteerd op basis van de URL. Als er twee verschillende URL's verwijzen naar dezelfde video, wordt deze waarschuwing weergegeven.
Afbeeldingsformaat kleiner dan aanbevolen formaat	De gestructureerde gegevens in de AMP verwijzen naar een afbeelding die kleiner is dan ons aanbevolen formaat. Hierdoor kan de pagina mogelijk niet worden weergegeven met alle AMP-gerelateerde functies op Google Zoeken. Het is ook mogelijk dat je Discover-kaarten hierdoor niet worden weergegeven met grote afbeeldingen (wat leidt tot minder websiteverkeer en gebruikersbetrokkenheid). Gebruik een grotere afbeelding volgens onze richtlijnen om het probleem op te lossen.
Domein van AMP-pagina komt niet overeen	De AMP-pagina wordt gehost op een ander domein dan de canonieke versie ervan. Dit kan verwarrend zijn voor mobiele gebruikers die het ene URL-domein in de zoekresultaten zien en een ander domein zien wanneer ze de pagina in de AMP-lezer openen. (Dit heeft geen invloed op de pagina-indexering of positie in de resultaten.)
URL niet gevonden (404)	De gevraagde AMP-URL kan niet worden gevonden. Meer informatie over het corrigeren van 404-pagina's.
Serverfout (5XX)	Niet-gespecificeerde 5XX-serverfout wanneer de AMP-pagina wordt aangevraagd. Meer informatie over serverfouten.
Geblokkeerd door robots.txt	De gevraagde AMP-URL is geblokkeerd door een robots.txt-regel. Als je dit niet wilt, test je je robots.txt-bestand op de blokkaderegel. Daarna pas je de regel aan of verwijder je deze (of vraag je je webontwikkelaar dit voor je te doen).
Crawlprobleem	Niet-gespecificeerde crawlfout voor de AMP-pagina. Gebruik de URL-inspectietool voor je AMP-URL om het probleem op te lossen.
De AMP-URL waarnaar wordt verwezen, is geen AMP	Een canonieke pagina verwijst naar een AMP die geen AMP-pagina is. Meer informatie over hoe een niet-AMP-pagina moet verwijzen naar een AMP-pagina.
De AMP-URL waarnaar wordt verwezen, is een zelfcanonieke AMP	De canonieke pagina verwijst naar een zelfstandige AMP. Je kunt niet naar een zelfstandige AMP verwijzen als de AMP-versie van een pagina. Meer informatie over hoe je naar een AMP kunt verwijzen vanaf een niet-AMP-pagina.
URL gemarkeerd als 'noindex'	AMP wordt geblokkeerd door een 'noindex'-instructie. Google kan een pagina die wordt geblokkeerd door noindex, niet indexeren. Verwijder de noindex-instructie of verwijder de verwijzing naar de geblokkeerde pagina.
Datum voor 'unavailable_after' voor deze pagina is verstreken	AMP-pagina heeft een 'unavailable_after'-metatag of -instructie die al is verstreken, wat aangeeft dat de pagina niet meer moet worden weergegeven. Update de tag naar een datum in de toekomst of verwijder de tag.
Canonieke URL verwijst naar een ongeldige URL	Een canonieke pagina verwijst naar een AMP-versie met een onjuist opgemaakte URL. Meer informatie over hoe je correct verwijst naar een AMP-versie.
Canonieke fout met amp-story	Een pagina verwijst ten onrechte naar een amp-story-pagina als de AMP-versie. Dit is niet toegestaan omdat een amp-story-pagina per definitie zelfcanoniek is. De pagina moet naar zichzelf verwijzen met een <rel="canonical">-tag en kan niet worden weergegeven als een AMP-versie van een andere pagina.
Modulescript gedefinieerd zonder nomodule-alternatief (of omgekeerd)	Je gebruikt een <script type="module">-tag zonder overeenkomende <script nomodule async>-tag of omgekeerd. Deze tags moeten in overeenkomende paren worden gebruikt om correcte verwerking mogelijk te maken door browsers die modulescripts wel of niet ondersteunen.
Ontbrekende URL in HTML-tag	De opgegeven HTML-tag vereist een kenmerk met een geldige URL die niet nul is, maar de URL is een lege tekenreeks. Geef een geldige URL voor het gemarkeerde kenmerk op.
Het kenmerk ontbreekt of is onjuist, maar wordt vereist door het kenmerk 'on'	Het opgegeven kenmerk is vereist, maar is onjuist of ontbreekt. Dit kenmerk is vereist omdat je een kenmerk 'on' hebt opgegeven in dezelfde tag.
Onderliggende <svg>-tag gevonden buiten een <svg>-blok	Je hebt een tag buiten een <svg>-blok opgegeven die moet worden genest in een <svg>-blok.
De pagina laadt meerdere versies van hetzelfde extensiescript	De pagina laadt meerdere versies van dezelfde AMP-extensie. Verwijder een versie van het script om het probleem te verhelpen.

Problemen met ondertekende uitwisseling

In het AMP-statusrapport en het URL-inspectierapport kunnen problemen worden weergegeven voor AMP's die gebruikmaken van het protocol voor ondertekende uitwisseling.

Informatie over een probleem met de ondertekende uitwisseling bekijken

Je kunt op meerdere plaatsen informatie vinden over de ondertekende uitwisseling die is gekoppeld aan een AMP:

• Klik in de URL-inspectietool op het probleem bij Details over AMP-versie.
• Klik in het AMP-statusrapport op een URL in de tabel met probleemgegevens.

Controleren of de AMP ondertekende uitwisseling gebruikt

Je kunt als volgt zien of Google headers of payloads voor ondertekende uitwisseling heeft gedetecteerd voor je AMP:

1. Inspecteer de AMP-URL (gebruik de URL-inspectietool om een specifieke URL te inspecteren of klik in het AMP-statusrapport op het pictogram voor inspecteren naast de URL in de tabel met probleemgegevens).
2. Klik op Gecrawlde pagina bekijken op de resultatenpagina om een zijvenster met meer informatie te openen.
3. Klik op het tabblad Meer informatie.
4. Onder het label Ondertekende uitwisseling zie je een status die aangeeft of Google componenten voor ondertekende uitwisseling heeft gedetecteerd voor die AMP.

Lijst van problemen met ondertekende uitwisseling

De volgende problemen kunnen optreden als je AMP het protocol voor ondertekende uitwisseling gebruikt.

• De ondertekende uitwisseling is ongeldig
• De payload van de ondertekende uitwisseling bevat een parseerfout
• De header 'header_name' voor de payload van de ondertekende uitwisseling heeft een ongeldige waarde
• De verplichte header 'header_name' voor de payload van de ondertekende uitwisseling ontbreekt
• De handtekeningsheader voor de ondertekende uitwisseling kan niet worden geparseerd
• De parameter 'parameter_name' in de handtekeningsheader van de ondertekende uitwisseling is ongeldig
• De datums voor de ondertekende uitwisseling zijn ongeldig
• De certificaatketen waarnaar wordt verwezen door de ondertekende uitwisseling 'cert-url' kan niet worden geparseerd
• De certificaatketen waarnaar wordt verwezen door 'cert-url' is ongeldig voor de ondertekende uitwisseling
• De ondertekende uitwisseling kan niet worden geparseerd
• De URL voor de binnenste payload komt niet overeen met de verzoek-URL voor de ondertekende uitwisseling
• De header 'header_name' van de HTTP-reactie voor de ondertekende uitwisseling heeft een ongeldige waarde

De ondertekende uitwisseling is ongeldig

De HTTP-reactie was een ondertekende uitwisseling die niet voldeed aan de vereisten voor de Google AMP Cache. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Deze fout kan verschillende oorzaken hebben, waaronder:

• Er is een header die niet is toegestaan door de specificatie voor ondertekende uitwisseling of door de Google AMP Cache.
• De validity-url heeft niet dezelfde oorsprong als de fallbackUrl, volgens de specificatie voor ondertekende uitwisseling.
• De headers van ondertekende reacties zijn niet canoniek gecodeerd.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De payload van de ondertekende uitwisseling bevat een parseerfout

De HTTP-reactie is een ondertekende uitwisseling waarvan de payload (hoofdtekst) niet voldeed aan de vereisten voor de Google AMP Cache. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Volg deze stappen om de fout te vinden en op te lossen:

• Controleer of de html geen ongeldige UTF-8-codering bevat. Voor de $URL die een fout oplevert, voer je het volgende uit: curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null. Check vervolgens of er foutmeldingen zijn, bijvoorbeeld over een ongeldige invoervolgorde. Als dit zo is, moet je ervoor zorgen dat het document correct wordt gecodeerd met UTF-8. Twee veelvoorkomende bronnen van multibyte-tekens zijn niet-Engelse tekst en spaties.
• Controleer of de html geen U+0000 NULL of Unicode-teken bevat dat een html-parseerfout veroorzaakt.
• Controleer of de html ongewijzigd is nadat je transform -config NONE hebt aangeroepen. Er zijn 2 veelvoorkomende redenen om dit te wijzigen:
  • Het bestand is geserialiseerd met een andere printer dan die gebundeld is met AMP Packager. Als je een andere generator voor ondertekende uitwisseling gebruikt, controleer je of deze de transformatiebibliotheek van AMP Packager gebruikt.
  • De html veroorzaakt een parseerfout die wordt afgehandeld door de parseerstructuur te wijzigen. Zulke fouten worden vaak veroorzaakt door weggelaten of verkeerd geplaatste eindtags. Voorbeelden hiervan zijn het adoption agency-algoritme en de verwerking van eindtags van formulieren. De diagnose van deze fouten is moeilijk. Met een html-opmaakvalidator kun je de oorzaak mogelijk achterhalen.
  • Als je het bovenstaande hebt uitgesloten:
    • Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.
    • Als je AMP Packager gebruikt:
      • Check of je de nieuwste versie van AMP Packager gebruikt.
      • Als dit zo is, zit er mogelijk een bug in AMP Packager. Meld een bug.

De header 'header_name' voor de payload van de ondertekende uitwisseling heeft een ongeldige waarde

De HTTP-reactie is een ondertekende uitwisseling met een ondertekende reactieheader die niet voldeed aan alle vereisten voor Google AMP Cache. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De verplichte header 'header_name' voor de payload van de ondertekende uitwisseling ontbreekt

De HTTP-reactie is een ondertekende uitwisseling zonder de opgegeven header die is vereist volgens de specificatie voor ondertekende uitwisseling of de vereisten voor de Google AMP Cache. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De handtekeningsheader voor de ondertekende uitwisseling kan niet worden geparseerd

De HTTP-reactie is een ondertekende uitwisseling met een handtekeningsheader die niet goed is opgemaakt volgens de specificatie voor ondertekende uitwisseling. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De parameter 'parameter_name' in de handtekeningsheader van de ondertekende uitwisseling is ongeldig

De HTTP-reactie is een ondertekende uitwisseling waarvan de handtekeningsheader een onjuiste waarde heeft voor de opgegeven parameter, zoals vereist door de specificatie voor ondertekende uitwisseling. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De datums voor de ondertekende uitwisseling zijn ongeldig

De HTTP-reactie is een ondertekende uitwisseling waarvan de handtekeningsheader een onjuiste waarde heeft voor de parameter date of expires, zoals vereist door de specificatie voor ondertekende uitwisseling of de vereisten voor de Google AMP Cache. (De handtekening moet geldig zijn op het moment dat deze wordt opgehaald en ten minste 4 dagen in de toekomst.) Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt, kan dit verschillende oorzaken hebben:

• Check of de omgekeerde proxy van de frontend de reacties van ondertekende uitwisseling niet te lang in de cache opslaat. Doe meerdere verzoeken voor de pagina met curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' en zoek in elke reactie naar "date=". Controleer of het volgnummer steeds verschilt.
• Check of je de nieuwste versie van AMP Packager gebruikt.
• Als je al het bovenstaande hebt uitgesloten, zit er mogelijk een bug in AMP Packager. Meld een bug.

De certificaatketen waarnaar wordt verwezen door de ondertekende uitwisseling 'cert-url' kan niet worden geparseerd

De HTTP-reactie is een ondertekende uitwisseling waarvan de cert-url niet goed is samengesteld volgens de specificatie voor ondertekende uitwisseling. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt:

• Check of je de nieuwste versie van AMP Packager gebruikt.
• Zo ja, dan kun je een bug melden.

De certificaatketen waarnaar wordt verwezen door 'cert-url' is ongeldig voor de ondertekende uitwisseling

De HTTP-reactie is een ondertekende uitwisseling waarvan de cert-url ongeldig is volgens de specificatie voor ondertekende uitwisseling. Hierdoor wordt de pagina aan gebruikers getoond zonder informatie over de handtekening.

Impact op je site:

De pagina wordt in een AMP-viewer weergegeven met een Google-URL in plaats van de oorspronkelijke URL.

Volgende stappen:

Deze fout oplossen is optioneel. Pagina's met deze fout worden nog steeds correct weergegeven in een AMP-viewer. Lees verder als je deze pagina wilt weergeven met de ondertekende URL.

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt, kan deze fout verschillende oorzaken hebben. Zaken die je kunt checken:

• Check of de CertFile geen volledige lijst van het leafcertificaat plus tussencertificaten bevat.
• Check of AMP Packager niet is gestart met de vlag -development of -invalidcert. In de productiemodus controleert AMP Packager verschillende aspecten van het certificaat.
• Check of de omgekeerde proxy van de frontend URL's met /amppkg/cert/ niet langer in het cachegeheugen opslaat dan is ingesteld voor hun max-age.
• Check of de omgekeerde proxy van de frontend geen cacheheaders wijzigt, want dit kan ertoe leiden dat een upstreamproxy deze certificaatketens te lang in het cachegeheugen opslaat. Je kunt dit testen door de betreffende URL met /amppkg/cert/ in je interne packager-domein vast te stellen en deze op te halen inclusief reactieheaders (bijvoorbeeld curl -i). Vervolgens vergelijk je deze reactieheaders met de headers die door de frontendserver worden geretourneerd.
• Check of je certificaat een SCT bevat, bijvoorbeeld met de tool openssl x509. Als dit niet zo is, neem je contact op met je certificeringsinstantie.
• Check of je de nieuwste versie van AMP Packager gebruikt.
• Als je al het bovenstaande hebt uitgesloten, zit er mogelijk een bug in AMP Packager. Meld een bug.

De ondertekende uitwisseling kan niet worden geparseerd

De HTTP-reactie heeft het inhoudstype application/signed-exchange; v=b3, maar de hoofdtekst van de reactie kan niet worden opgehaald. Dit kan zijn omdat niet is voldaan aan de algemene vereisten van dit type of omdat de Merkle-codering van de payload niet goed is.

Impact op je site:

Als de pagina een bijbehorende niet-AMP-pagina heeft, indexeert Google Zoeken die pagina. Anders wordt de pagina mogelijk helemaal niet weergegeven op Google Zoeken.

Volgende stappen:

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt, kan dit verschillende oorzaken hebben:

• Check of de omgekeerde proxy van de frontend de reacties van de packager niet wijzigt. Bepaal voor de URL die een fout oplevert de bijbehorende URL met /priv/doc in je interne packager-domein en test deze met dump-signedexchange. Als de reactie van de interne packager een geldige ondertekende uitwisseling is, maar de externe frontendreactie dat niet is, zit er waarschijnlijk een configuratiefout in de frontend.
• Check of je de nieuwste versie van AMP Packager gebruikt.
• Als je al het bovenstaande hebt uitgesloten, zit er mogelijk een bug in AMP Packager. Meld een bug.

De URL voor de binnenste payload komt niet overeen met de verzoek-URL voor de ondertekende uitwisseling

De HTTP-reactie is een ondertekende uitwisseling waarvan fallbackUrl niet overeenkomt met de verzoek-URL. Ze moeten byte voor byte gelijk zijn. Hierdoor vertrouwt Google Zoeken niet dat de reactie representatief is voor de verzoek-URL.

Impact op je site:

Als de pagina een bijbehorende niet-AMP-pagina heeft, indexeert Google Zoeken die pagina. Anders wordt de pagina mogelijk helemaal niet weergegeven op Google Zoeken.

Volgende stappen:

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp. Een mogelijke oplossing is om de URL van de pagina te wijzigen om bugs in veelgebruikte URL-parsers te voorkomen. Probeer bijvoorbeeld tekens te verwijderen die als percentage gecodeerd zijn of die gereserveerd zijn. Of verwijder coderingen die ongebruikelijk zijn voor querytekenreeksen, zoals een ? zonder parameters.

Als je AMP Packager gebruikt, kan dit verschillende oorzaken hebben:

• Check of URL's correct worden herschreven door de omgekeerde proxy van de frontend. De kans op problemen is groter bij URL's met tekens die als percentage gecodeerd zijn of die gereserveerd zijn. Zo heeft nginx problemen met de herschrijvingsinstructie en de padloze vorm van de proxy_pass-instructie. Test dit door enkele testverzoeken naar je frontend te sturen. Vergelijk deze met de URL's die AMP Packager bij stdout registreert.
• Check of je de nieuwste versie van AMP Packager gebruikt.
• Als je al het bovenstaande hebt uitgesloten, zit er mogelijk een bug in AMP Packager. Meld een bug.

De header 'header_name' van de http-reactie voor de ondertekende uitwisseling heeft een ongeldige waarde

De HTTP-reactie heeft het inhoudstype application/signed-exchange, maar de reactieheaders zijn op een andere manier ongeldig. In content-type ontbreekt bijvoorbeeld de parameter v=b3. Hierdoor is de indeling onbekend voor Google en kan de hoofdtekst van de reactie niet worden opgehaald.

Impact op je site:

Als de pagina een bijbehorende niet-AMP-pagina heeft, indexeert Google Zoeken die pagina. Anders wordt de pagina mogelijk helemaal niet weergegeven op Google Zoeken.

Volgende stappen:

Als je voor ondertekende uitwisseling een serviceprovider gebruikt, kun je daar contact mee opnemen voor hulp.

Als je AMP Packager gebruikt, kan dit verschillende oorzaken hebben:

• Check of de omgekeerde proxy van de frontend de headers van content-type niet wijzigt. Bepaal voor de URL die een fout oplevert de bijbehorende URL met /priv/doc in je interne packager-domein en haal deze op inclusief reactieheaders (bijvoorbeeld met curl -i). Als de headers van de reactie van de interne packager verschillen van de headers van de reactie van de externe frontend, kan dit de oorzaak van de fout zijn. Als het verschil zich in een andere header dan content-type bevindt, kun je het beste een bug melden over dit Help-document. Meld daarin dat de lijst met vereisten moet worden aangepast.
• Check of je de nieuwste versie van AMP Packager gebruikt.
• Als je al het bovenstaande hebt uitgesloten, zit er mogelijk een bug in AMP Packager. Meld een bug.

Problemen prioriteit geven en oplossen

1. Bekijk de lijst met kritieke problemen voor je site in de tabel Waarom AMP-pagina's ongeldig zijn.
2. Analyseer de fouten:
   • Ga na of een toename in het totale aantal fouten vooral wordt veroorzaakt door één fout. Zoek hiervoor naar een overeenkomende piek bij één probleem in de tabel.
   • Los eerst fouten op die worden veroorzaakt door een veelvoorkomende oorzaak (zoals een verkeerde template). Los vervolgens fouten op die uniek zijn voor elke pagina.
3. Corrigeer de fouten: Klik op een rij in de tabel om de detailpagina van de fout te bekijken:
   1. De detailpagina bevat een voorbeeld van de getroffen URL's. De lijst is beperkt tot 1000 rijen en bevat mogelijk geen zeer recent ontdekte instanties van deze fout of pagina's die niet opnieuw zijn gecrawld sinds de fout is opgetreden.
   2. Klik naast een probleem op Meer informatie om officiële documentatie over de fout te bekijken.
   3. Klik op een URL in de tabel met voorbeeld-URL's om het probleem in de paginacode te markeren.
   4. Klik op het inspectie-icoon  om een gedetailleerde test uit te voeren voor een specifieke pagina. Deze test identificeert alle fouten (niet alleen het huidige probleem) en biedt een codeverkenner waarin de fouten met bijbehorende aanvullende informatie worden getoond. Als de pagina niet recent opnieuw is gecrawld, zie je het probleem voor de geïndexeerde pagina, maar niet voor de live pagina. In dat geval kun je indexering van die specifieke pagina aanvragen.
   5. Los alle instanties van het probleem op je site op, test je oplossing en zorg ervoor dat je oplossingen live op internet zijn.
4. Als je alle instanties hebt opgelost, ga je terug naar de detailpagina van het probleem en klik je op de knop Oplossing valideren om het validatieproces te starten. Dit proces vindt niet onmiddellijk plaats. Bekijk Over validatie voor meer informatie over het validatieproces.
5. Ga door met fouten oplossen.
6. Als het aantal geldige en ongeldige pagina's aanzienlijk lager is dan het aantal AMP-pagina's op je site, bekijk je Problemen met ontbrekende AMP-pagina's oplossen.
7. Als alle kritieke fouten zijn opgelost, kun je eventueel de niet-kritieke problemen oplossen. Sommige niet-kritieke problemen (bijvoorbeeld het gebruik van beëindigde functies) kunnen in de toekomst kritiek worden.

Het rapport delen

Je kunt probleemgegevens delen in de dekkings- of optimalisatierapporten delen door op de knop Delen op de pagina te klikken. Via deze link krijgt iedereen die de link heeft, alleen toegang tot de huidige pagina met probleemgegevens en eventuele validatiegeschiedenispagina's voor dit probleem. De link geeft geen toegang tot andere pagina's voor je bron en geeft de gebruiker waarmee de link is gedeeld, niet de mogelijkheid om acties voor je property of account uit te voeren. Je kunt de link op elk gewenst moment intrekken door delen uit te schakelen voor deze pagina.

Rapportgegevens exporteren

Veel rapporten bevatten een exportknop om de rapportgegevens te exporteren. Zowel diagram- als tabelgegevens worden geëxporteerd. Waarden die worden weergegeven als ~ of - in het rapport (niet beschikbaar/geen cijfer), zijn nullen in de gedownloade gegevens.

Problemen met ontbrekende AMP-pagina's oplossen

Als het aantal AMP-pagina's (geldig + ongeldig) in het rapport lager is dan het aantal AMP-pagina's op je site, zijn dit enkele mogelijke redenen:

• Check of je canonieke niet-AMP-pagina correct is gekoppeld aan je AMP-pagina.
• Ga na of je AMP- of canonieke pagina's niet voor robots zijn geblokkeerd of voorzien zijn van een noindex-tag, of worden beschermd door inlogvereisten.
• Check de URL van de canonieke pagina voor je AMP om te zien of deze is geïndexeerd.
  • Als de canonieke pagina wordt vermeld, check je of je canonieke niet-AMP-pagina correct is gekoppeld aan je AMP-pagina.
  • Als de canonieke pagina niet wordt vermeld, dien je deze in voor indexering.
• Het kan enkele dagen duren voordat Google de ontbrekende pagina's vindt en crawlt, afhankelijk van hoe je Google op de hoogte stelt van de nieuwe pagina's.
• Sommige geldige AMP-pagina's zijn mogelijk niet opgenomen in dit rapport, ook al worden ze wel vermeld in het rapport Pagina-indexering. Dit komt omdat het rapport Pagina-indexering uitgebreider moet zijn om je te helpen bij de opsporing van indexeringsproblemen in je rapport, terwijl het AMP-statusrapport mogelijk minder, maar wel relevantere pagina's bevat (met meer details), zodat je specifieke AMP-fouten op je site kunt opsporen. Als je wilt checken of een AMP-pagina is geïndexeerd, gebruik je de URL-inspectietool. Deze kan je het definitieve antwoord geven.

Nadat je alle instanties van een specifiek probleem op je site hebt verholpen, kun je Google vragen je oplossingen te bevestigen. Als alle bekende instanties zijn opgelost, wordt de telling voor het aantal problemen in de tabel met problemen op 0 gezet en wordt het probleem onderaan de tabel geplaatst.

Waarom valideren?

Google laat weten dat je alle problemen met een bepaalde probleemstatus of in een bepaalde categorie hebt opgelost, biedt je de volgende voordelen:

• Je krijgt een e-mail als Google je oplossing heeft bevestigd voor alle URL's of als Google resterende instanties van dat probleem heeft gevonden.
• Je kunt de voortgang van Google bij de bevestiging van je oplossingen volgen en een logboek bekijken met alle pagina's die in de wachtrij voor controle staan plus de oplossingsstatus van elke URL.

Het is misschien niet altijd zinvol om een specifiek probleem op je website op te lossen en te valideren. URL's die bijvoorbeeld door robots.txt worden geblokkeerd, worden waarschijnlijk opzettelijk geblokkeerd. Maak zelf een inschatting om een bepaald probleem wel of niet aan te pakken.

Je kunt ook problemen oplossen zonder de oplossingen te valideren. Google updatet de telling van het aantal instanties als een pagina met bekende problemen wordt gecrawld, ongeacht of je expliciet om validatie van de oplossing vraagt.

Tip voor gevorderden: je oplossingen valideren via een sitemap

Als je een oplossingsverzoek wilt versnellen, maak je een sitemap die alleen je belangrijkste pagina's bevat en dien je deze in. Filter het rapport daarna op die sitemap voordat je een oplossingsvalidatie aanvraagt. Een validatieverzoek voor een subset van je getroffen URL's kan sneller worden afgerond dan een verzoek dat alle getroffen URL's op je site bevat.

Validatie starten

Zo laat je Search Console weten dat je een probleem hebt opgelost:

1. Verhelp alle instanties van het probleem op je site. Als je een oplossing hebt gemist, stopt de validatie als Google één enkele resterende instantie van dat probleem vindt.
2. Open de detailpagina van het probleem dat je hebt opgelost. Klik in de lijst met problemen in je rapport op het probleem.
   • ⚠️ Als je hebt gefilterd op een specifieke sitemap in je rapport, is de validatie alleen van toepassing op items in de sitemap op het moment dat je de validatie hebt aangevraagd. Dit is misschien wat je wilt, maar misschien ook niet. Wees je daar dus bewust van.
3. Klik op Oplossing valideren. Klik niet opnieuw op Oplossing valideren totdat de validatie is geslaagd of mislukt. Meer informatie over hoe Google je oplossingen checkt.
4. Je kunt de validatievoortgang bijhouden. Validatie duurt meestal ongeveer 2 weken, maar kan in sommige gevallen veel langer duren. Wacht dus geduldig af. Je krijgt een melding als de validatie is geslaagd of mislukt.
5. Als de validatie mislukt, kun je zien welke URL daarvoor heeft gezorgd. Klik hiervoor op Details bekijken op de detailpagina van het probleem. Los het probleem op deze pagina op, bevestig je oplossing voor alle URL's met de status In behandeling en start de validatie opnieuw.

Wanneer wordt een probleem met een URL of item beschouwd als opgelost?

Een probleem met een URL of item wordt gemarkeerd als opgelost wanneer aan een van de volgende voorwaarden wordt voldaan:

• Wanneer de URL wordt gecrawld, wordt het probleem niet meer op de pagina aangetroffen. In geval van een AMP-tagfout kan dit betekenen dat de tag is aangepast of dat de tag is verwijderd (als de tag niet is vereist). Tijdens een validatiepoging krijgt de tag het label Geslaagd.
• Als de pagina om welke reden dan ook niet beschikbaar is voor Google (de pagina is verwijderd, de pagina heeft een noindex-instructie, de pagina vereist verificatie, enz.), wordt het probleem voor die URL als opgelost beschouwd. Tijdens een validatiepoging wordt de pagina in de categorie met de validatiestatus Overig geplaatst.

De levensduur van een probleem

De levensduur van een probleem begint zodra de eerste instantie van het probleem is gevonden op je site. De levensduur eindigt 90 dagen nadat de laatste instantie op je site is gemarkeerd als opgelost. Als het probleem de daaropvolgende 90 dagen niet terugkeert, wordt het probleem uit de tabel met problemen verwijderd.

De datum van eerste detectie van een probleem is het moment waarop het probleem voor het eerst tijdens de levensduur van het probleem wordt gevonden. Deze datum kan niet worden gewijzigd. Dit houdt het volgende in:

• Als alle instanties van een probleem zijn opgelost, maar het probleem zich 15 dagen later opnieuw voordoet, wordt het probleem gemarkeerd als openstaand en blijft de datum waarop het probleem voor het eerst werd gevonden de oorspronkelijke datum.
• Als hetzelfde probleem zich 91 dagen nadat de laatste instantie is opgelost opnieuw voordoet, was het vorige probleem gesloten en wordt dit probleem als een nieuw probleem geregistreerd. De datum voor de eerste detectie wordt ingesteld op de nieuwe detectiedatum.

Validatieproces

Hier volgt een overzicht van het validatieproces nadat je voor een probleem op Oplossing valideren hebt geklikt. Dit proces kan een paar dagen of zelfs langer duren en je krijgt voortgangsmeldingen via e-mail.

1. Als je op Oplossing valideren klikt, checkt Search Console onmiddellijk een aantal pagina's.
   • Als de huidige instantie op een van deze pagina's voorkomt, wordt de validatie beëindigd en blijft de validatiestatus ongewijzigd.
   • Als de voorbeeldpagina's niet de huidige fout bevatten, wordt de validatie voortgezet met de status Gestart. Als er tijdens de validatie andere, niet-gerelateerde problemen worden aangetroffen, worden deze problemen meegeteld voor het andere type probleem en wordt de validatie voortgezet.
2. Search Console werkt de lijst af met bekende URL's waarop dit probleem van toepassing is. Alleen URL's met bekende instanties van dit probleem worden in de wachtrij voor opnieuw crawlen geplaatst, niet de hele site. Search Console houdt in de validatiegeschiedenis bij welke URL's zijn gecheckt. Je kunt de validatiegeschiedenis bekijken via de detailpagina met probleemgegevens.
3. Als een URL wordt gecheckt, kunnen de volgende situaties zich voordoen:
   1. Als het probleem niet wordt gevonden, wordt de validatiestatus voor het probleem gewijzigd in Geslaagd. Als dit de eerste instantie is die wordt gecheckt nadat de validatie is gestart, wordt de validatiestatus voor het probleem gewijzigd in Dat ziet er goed uit.
   2. Als de URL niet meer bereikbaar is, wordt de validatiestatus voor de instantie gewijzigd in Overig (dit is geen foutstatus).
   3. Als de instantie nog altijd wordt aangetroffen, wordt de probleemstatus gewijzigd in Mislukt en wordt de validatie beëindigd. Als dit een nieuwe pagina is die wordt ontdekt tijdens een reguliere crawl, wordt de fout beschouwd als nog een instantie van het bestaande probleem.
4. Als URL's in de wachtrij zijn gecheckt op dit probleem en er is vastgesteld dat het probleem is opgelost, wordt de probleemstatus gewijzigd in Geslaagd. Zelfs als alle instanties zijn opgelost, verandert het label met de ernst van het probleem (Fout of Waarschuwing) niet maar wordt alleen het aantal getroffen items (0) weergegeven.

Zelfs als je nooit op Validatie starten klikt, kan Google opgeloste instanties van een probleem vinden. Als Google tijdens een reguliere crawl vaststelt dat alle instanties van een probleem zijn opgelost, wordt de telling van het aantal problemen in het rapport op 0 gezet.

Opnieuw valideren

⚠️ Je moet wachten totdat een validatiecyclus is afgerond voordat je een andere cyclus aanvraagt, ook wanneer je tijdens de huidige cyclus een paar problemen hebt opgelost.

Zo start je een mislukte validatie opnieuw:

1. Ga naar het validatielogboek voor de mislukte validatie: Open de detailpagina van het probleem waarvoor de validatie is mislukt en klik op Details bekijken.
2. Klik op Nieuwe validatie starten.
3. De validatie wordt opnieuw gestart voor alle URL's met de markering In behandeling of Mislukt en voor nieuwe instanties van dit probleem die sinds de laatste validatiepoging tijdens een reguliere crawl zijn ontdekt. URL's met de markering Geslaagd of Overig worden niet opnieuw gecheckt.
4. Validatie duurt meestal ongeveer 2 weken, maar kan in sommige gevallen veel langer duren. Wacht dus geduldig af.

De validatievoortgang bekijken

Zo bekijk je de voortgang van een lopend validatieverzoek of de geschiedenis van het laatste verzoek als er geen openstaand validatieverzoek is:

1. Open de detailpagina van het probleem. Klik op de rij met problemen op de hoofdpagina van het rapport om de detailpagina van het probleem te openen.
   • De status van het validatieverzoek wordt getoond op zowel de detailpagina van het probleem als in de rij Validatie van de tabel Details.
2. Klik op Details bekijken om de pagina met validatiedetails voor dat verzoek te openen.
   • De instantiestatus voor elke URL in het verzoek wordt weergegeven in de tabel.
   • De instantiestatus is van toepassing op het specifieke probleem dat je onderzoekt. Op een pagina kun je 1 probleem met het label Geslaagd hebben, terwijl andere problemen op dezelfde pagina het label Mislukt, In behandeling of Overig hebben.
   • In het AMP-rapport en het rapport Pagina-indexering worden items op de pagina met de validatiegeschiedenis gegroepeerd op URL.
   • In de rapporten Uitgebreid resultaat worden items gegroepeerd op basis van de combinatie van URL en gestructureerd gegevensitem (zoals bepaald door de naamwaarde van het item).

Status validatieverzoek

De volgende validatiestatussen zijn van toepassing op de validatie voor een bepaald probleem:

• Niet gestart: Voor een of meer instanties van dit probleem is er nooit een validatieverzoek voor dit probleem ingediend.
  Volgende stappen:
  1. Klik op het probleem om de details van de fout te achterhalen. Inspecteer de afzonderlijke pagina's om voorbeelden van de fout op de live pagina te bekijken.
  2. Klik op Meer informatie op de detailpagina om de details van het probleem te bekijken.
  3. Klik in de tabel op een rij met voorbeeld-URL's om meer informatie over dat specifieke probleem weer te geven.
  4. Pas je pagina's aan en klik daarna op Oplossing valideren om de validatie te starten. Validatie duurt meestal ongeveer 2 weken, maar kan in sommige gevallen veel langer duren. Wacht dus geduldig af.
• Gestart: Er is een validatiepoging gestart en er zijn tot dusver geen instanties van het probleem gevonden.
  Volgende stap: Je krijgt meldingen van Google over de voortgang van de validatie en, zo nodig, instructies voor wat je moet doen.
• Dat ziet er goed uit: Er is een validatiepoging gestart en alle gecheckte instanties zijn opgelost.
  Volgende stap: Je hoeft verder niets te doen. Je krijgt meldingen van Google over de voortgang van de validatie en instructies voor wat je moet doen.
• Geslaagd: Alle bekende instanties van het probleem zijn verdwenen (of de betreffende URL is niet langer beschikbaar). Je moet op Oplossing valideren hebben geklikt om deze status te bereiken (als er instanties zijn verdwenen zonder dat je om een validatie hebt gevraagd, wordt de status gewijzigd in N.v.t.).
  Volgende stap: Je hoeft verder niets te doen.
• N.v.t.: Google heeft vastgesteld dat het probleem voor alle URL's is opgelost, ondanks dat er nooit een validatiepoging is gestart.
  Volgende stap: Je hoeft verder niets te doen.
• Mislukt: Nadat je op Valideren hebt geklikt, doet het probleem zich nog altijd op een bepaald aantal pagina's voor.
  Volgende stappen: Los het probleem op en start de validatie opnieuw.

Validatiestatus van instantie

Nadat validatie is aangevraagd, wordt aan elke instantie van het probleem een van de volgende validatiestatussen toegewezen:

• In behandeling: De instantie is in de wachtrij voor validatie geplaatst. Tijdens de laatste controle door Google bestond deze instantie van het probleem nog steeds.
• Geslaagd: [Niet beschikbaar in alle rapporten] Na controle door Google blijkt dat de instantie van het probleem zich niet meer voordoet. Deze status kan alleen worden bereikt als je voor deze instantie van het probleem expliciet op Valideren hebt geklikt.
• Mislukt: Na controle door Google blijkt dat de instantie van het probleem zich nog steeds voordoet. Deze status kan alleen worden bereikt als je voor deze instantie van het probleem expliciet op Valideren hebt geklikt.
• Overig: [Niet beschikbaar in alle rapporten] Google kan de URL die als host voor de instantie fungeert niet bereiken of kan het item niet meer op de pagina vinden (voor gestructureerde gegevens). Wordt beschouwd als gelijk aan Geslaagd.

Houd er rekening mee dat dezelfde URL verschillende statussen voor verschillende problemen kan hebben. Als bijvoorbeeld zowel probleem X als probleem Y zich op een pagina voordoet, kan probleem X de validatiestatus Geslaagd hebben, terwijl probleem Y op dezelfde pagina de status In behandeling kan hebben.

 

Bekende problemen

Hieronder zie je bekende problemen in Search Console. Het is niet nodig deze aan ons te melden, maar we stellen je feedback over andere functies of problemen die je tegenkomt op prijs. Gebruik de functie Feedback die is ingebouwd in de navigatiebalk.

• Sommige problemen hebben lange namen die niet gemakkelijk te begrijpen zijn.
• Er kan een vertraging optreden tussen het moment waarop een probleem aan het diagram wordt toegevoegd en het moment waarop dit aan de tabel wordt toegevoegd.