Statusrapport for AMP

Denne rapport hjælper dig med at rette fejl, der forhindrer, at dine AMP-sider vises i Google-søgeresultater med AMP-specifikke funktioner.

I den overordnede visning kan du se alle de AMP-sider, som Google registrerede fejl for på dit website. De er grupperet efter problemtype. Klik på et bestemt problem for at se oplysninger om problemet, bl.a. en liste med eksempler på sider, der er berørt af det pågældende problem, oplysninger om, hvordan du løser det, og en proces til at underrette Google om dine problemløsninger.

Du kan se diagrammer, der viser indvirkningen af problemer og rettelser, ved at gå til siden Status.

Hvorfor er denne liste ikke komplet? Vi viser så mange af de sider, der berørt af fejl, som vi kan. Der kan dog ikke vises flere end 1.000 webadresser i tabellen. Det er også muligt, at der findes yderligere sider, som vi af ukendte årsager ikke har registreret eller talt.

ÅBN AMP-RAPPORTEN

Statusrapport for AMP i Search Console – Google Search Console-kurser

Kig efter følgende

Du bør kunne se følgende i rapporten:

  • Nul AMP-fejl på dit website (advarsler betragtes som anbefalinger og ikke fejl – se afsnittet Om advarsler nedenfor). Gå til afsnittet Prioriter og løs problemer, hvis der er AMP-fejl på dit website.
  • Det samlede antal AMP-sider i rapporten (gyldig + advarsel + fejl) bør stemme nogenlunde overens med antallet af AMP-sider på dit website. Hvis dette ikke er tilfældet, skal du gå til afsnittet Manglende AMP-sider.

Liste over AMP-problemer

Ud over almindelige AMP-specifikke fejl kan rapporten afsløre følgende andre problemer (fejl og advarsler).

Google-specifikke AMP-problemer
Problem Beskrivelse
Indholdet matcher ikke: Mangler indlejret video Der er en integreret video på den kanoniske webside, som ikke findes i AMP-versionen. Det er normalt bedst at medtage alle de samme vigtige indholdsressourcer i din AMP-version som på den kanoniske webside. Bemærk, at videoen registreres ved hjælp af webadressen. Hvis du har to forskellige webadresser, der peger på den samme video, får du denne advarsel.
Billedet er mindre end den anbefalede størrelse De strukturerede data på AMP-siden henviser til et billede, der er mindre end vores anbefalede størrelse. Dette kan forhindre, at siden vises med alle AMP-relaterede funktioner i Google Søgning, og kan også betyde, at dine Discover-kort ikke vises med store billeder (hvilket medfører et fald i websitetrafik og brugerengagement). Du kan løse problemet ved at bruge et større billede i overensstemmelse med vores retningslinjer.
Uoverensstemmelse i AMP-domæne AMP-siden hostes på et andet domæne end dens kanoniske version. Dette kan være forvirrende for brugere, der foretager søgninger på mobilenheder, da de får vist ét webadressedomæne i søgeresultaterne og et andet, når de åbner siden i AMP-læseren. (Dette påvirker ikke indekseringen eller rangeringen af sider).
Webadressen blev ikke fundet (404) Den AMP-webadresse, der blev anmodet om, blev ikke fundet. Få flere oplysninger om, hvordan du løser problemer med 404-sider.
Serverfejl (5xx) Uspecificeret 5XX-serverfejl ved anmodning om AMP-siden. Få flere oplysninger om serverfejl.
Blokeret af robots.txt Den anmodede AMP-webadresse blev blokeret af en robots.txt-regel.
Crawlproblem Uspecificeret crawlfejl for AMP-siden. Brug værktøjet til undersøgelse af webadresser på din AMP-webadresse til at finde og rette problemet. 
Den AMP-webadresse, der henvises til, er ikke en AMP En kanonisk side henviser til en AMP, der faktisk ikke er en AMP-side. Se, hvordan en ikke-AMP-side bør henvise til en AMP-side.
AMP-webadressen, der henvises til, er en selvstændig AMP Den kanoniske side henviser til en enkeltstående AMP. Du kan ikke henvise til en enkeltstående AMP-side som AMP-versionen af en side. Se, hvordan du henviser til en AMP-side fra en ikke-AMP-side.
Webadressen er angivet som "noindex" AMP-siden er blokeret af et "noindex"-direktiv. Google kan ikke indeksere en side, der er blokeret ved hjælp af noindex. Du kan enten fjerne noindex-direktivet eller fjerne henvisningen til den blokerede side.
"unavailable_after"-datoen for denne side er overskredet AMP-siden har et "unavailable_after"-metatag eller -direktiv i fortiden, hvilket indikerer, at den ikke længere skal vises. Du kan enten opdatere tagget til en fremtidig dato eller fjerne det.
Den kanoniske side henviser til en ugyldig webadresse En kanonisk side henviser til en AMP-version ved hjælp af en ugyldigt formateret webadresse. Se, hvordan du henviser korrekt til en AMP-version.
Kanonisk fejl i forbindelse med amp-story

En side henviser fejlagtigt til en side med amp-story som sin AMP-version. Dette er ikke tilladt, fordi en side med amp-story pr. definition er selvstændig. Den skal henvise til sig selv med et <rel="canonical">-tag og kan ikke fungere som AMP-version af en anden side.

Problemer med signed exchange

Både AMP-statusrapporten og rapporten til undersøgelse af webadresser kan vise problemer for AMP'er, der bruger signed exchange-protokollen.

Sådan ser du oplysninger om et problem med signed exchange

Du kan finde oplysninger om den signed exchange-forekomst, der er knyttet til en AMP, flere steder:

  • I værktøjet til undersøgelse af webadresser kan du klikke på problemet under Info om AMP-version.
  • I AMP-statusrapporten kan du klikke på en webadresse i tabellen med oplysninger om problemet.

Sådan ser du, om din AMP benytter signed exchange

Sådan ser du, om Google har registreret headere eller data med signed exchange for din AMP:

  1. Undersøg AMP-webadressen (du kan enten bruge værktøjet til undersøgelse af webadresser til at undersøge en bestemt webadresse eller klikke på inspektionsikonet i AMP-statusrapporten ud for webadressen i tabellen med oplysninger om problemet).
  2. Klik på Se crawlet side på resultatsiden for at åbne et sidepanel med flere oplysninger.
  3. Klik på fanen Flere oplysninger.
  4. Under etiketten Signed exchange kan du se en status, der angiver, om Google har registreret signed exchange-komponenter for den pågældende AMP.

Liste over problemer med signed exchange

De følgende problemer kan opstå, når din AMP bruger signed exchange-protokollen.

Signed exchange-forekomsten er ugyldig

HTTP-svaret var en signed exchange-forekomst, der ikke opfyldte kravene til Google AMP-cachen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Denne fejl kan opstå af flere årsager, bl.a:

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Der er en parsingfejl i signed exchange-dataene

HTTP-svaret var en signed exchange-forekomst med "data" (brødtekst), som ikke opfyldte kravene for Google AMP-cachen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Denne fejl kan opstå af flere årsager:

  • Bekræft, at HTML-koden ikke indeholder en ugyldig UTF-8-kodning. I forbindelse med den fejlramte $URL skal du køre curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null og tjekke, om du får fejlmeddelelser som f.eks. "illegal input sequence" (ulovlig inputsekvens). Hvis du får fejlmeddelelser, skal du sikre, at dokumentet er UTF-8-kodet korrekt. To almindelige kilder til fejl er tekst på andre sprog end engelsk og mellemrum.
  • Bekræft, at HTML-koden ikke indeholder U+0000 NULL eller et Unicode-tegn, der forårsager en HTML-parsingfejl.
  • Bekræft, at HTML-koden er uændret efter at have kaldt transform -config NONE. Der er to almindelige årsager til, at den kan ændres:

Der er en ugyldig værdi i headeren "header_name" for signed exchange-dataene

HTTP-svaret var en signed exchange-forekomst, der indeholdt en header med et signeret svar, der ikke opfyldte et af kravene til Google AMP Cache. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Den obligatoriske header "header_name" mangler for signed exchange-dataene

HTTP-svaret var en signed exhcange-forekomst, der manglede den header, der kræves enten af specifikationen for signed exchange-forekomster eller kravene til Google AMP-cachen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Signaturheaderen for signed exchange-forekomsten kan ikke parses

HTTP-svaret var en signed exchange-forekomst, der indeholdt en signaturheader, der ikke var korrekt udformet i henhold til signed exchange-specifikationen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Parameteren "parameter_name" er ugyldig i signaturheaderen med signed exchange

HTTP-svaret var en signed exchange-forekomst med en signaturheader, der havde en forkert værdi for den angivne parameter i henhold til kravene i signed exchange-specifikationen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Datoerne for signed exchange-forekomsten er ugyldige

HTTP-svaret var en signed exchange-forekomst med en signaturheader, der havde en forkert værdi for parameteren date eller expires i henhold til kravene i signed exchange-specifikationen eller kravene for Google AMP-cachen (specifikt skal signaturen være gyldig på det tidspunkt, hvor den hentes, og mindst fire dage ud i fremtiden). Derfor bliver siden præsenteret for brugerne uden nogen oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager, kan der være flere årsager:

  • Tjek, at din frontend-reverse-proxy ikke gemmer signed exchange-svar for længe i cachen. Foretag flere anmodninger for siden med curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any', og søg efter "date=" i hvert svar. Bekræft, at det efterfølgende tal er forskelligt hver gang.
  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du har udelukket alt det ovenstående, kan der være en fejl i AMP Packager. Rapportér en fejl.

Den certifikatkæde, der henvises til i "cert-url" for signed exchange-forekomsten, kan ikke parses

HTTP-svaret var en signed exchange-forekomst med en cert-url, der ikke var korrekt udformet i henhold til signed exchange-specifikationen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager:

  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du kører den nyeste version, skal du rapportere en fejl.

Den certifikatkæde, der henvises til i "cert-url", er ugyldig for denne signed exchange-forekomst

HTTP-svaret var en signed exchange-forekomst med en cert-url, der var ugyldig i henhold til signed exchange-specifikationen. Derfor bliver siden præsenteret for brugerne uden oplysninger fra signaturen.

Sådan påvirker det dit website:

Siden præsenteres i et AMP-visningsprogram med en Google-webadresse i stedet for dens oprindelige webadresse.

Næste trin:

Det er valgfrit, om du vil rette denne fejl. Sider med denne fejl vises stadig korrekt inde i et AMP-visningsprogram. Hvis du vil have siden vist med dens signerede webadresse, skal du læse videre.

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager, kan der være flere årsager til denne fejl. Nogle ting, du kan tjekke:

  • Tjek, at din CertFile ikke indeholder en komplet liste over bladcertifikatet og mellemliggende elementer.
  • Bekræft, at AMP Packager ikke blev startet med markeringen -development eller -invalidcert. I produktionstilstand bekræfter AMP Packager flere aspekter af certifikatet.
  • Tjek, at din frontend-reverse-proxy ikke gemmer /amppkg/cert/-webadresser i cachen i længere tid end angivet i dens max-age.
  • Tjek, at din frontend-reverse-proxy ikke ændrer cacheheadere. Dette kan medvirke, at en upstream-proxy gemmer disse certifikatkæder i cachen for længe. Du kan teste dette ved at finde den tilsvarende /amppkg/cert/-webadresse på dit interne packager-domæne, hente den og de tilhørende svarheadere (f.eks. med curl -i) og sammenligne svarheaderne med dem, der returneres af frontend-serveren.
  • Bekræft, at dit certifikat indeholder et SCT, f.eks. ved hjælp af værktøjet openssl x509. Hvis certifikatet ikke indeholder et SCT, skal du kontakte din certifikatautoritet.
  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du har udelukket alt det ovenstående, kan der være en fejl i AMP Packager. Rapportér en fejl.

Signed exchange-forekomsten kan ikke parses

HTTP-svaret havde indholdstypen application/signed-exchange; v=b3, men svarteksten kunne ikke trækkes ud. Det kan skyldes, at den ikke opfyldte de høje krav for den pågældende type, eller fordi dens data blev Merkle-kodet forkert.

Sådan påvirker det dit website:

Hvis siden har en tilsvarende ikke-AMP-side, indekserer Google Søgning den i stedet. Ellers vises siden muligvis slet ikke i Google Søgning.

Næste trin:

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager, kan der være flere årsager:

  • Tjek, at din frontend-reverse-proxy ikke ændrer svarene fra Packager. I forbindelse med den fejlramte webadresse skal du finde frem til den tilsvarende /priv/doc-webadresse på dit interne Packager-domæne og teste den ved hjælp af dump-signedexchange. Hvis det interne Packager-svar er en gyldig signed exchange-forekomst, men det eksterne frontend-svar ikke er, er der sandsynligvis en konfigurationsfejl i din frontend.
  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du har udelukket alt det ovenstående, kan der være en fejl i AMP Packager. Rapportér en fejl.

Webadressen for de indre data stemmer ikke overens med anmodningswebadressen for denne signed exchange-forekomst

HTTP-svaret var en signed exchange-forekomst med en fallbackUrl, der ikke matcher anmodningswebadressen. De skal svare til hinanden byte for byte. Google Søgning stoler derfor ikke på, at svaret er repræsentativt for anmodningswebadressen.

Sådan påvirker det dit website:

Hvis siden har en tilsvarende ikke-AMP-side, indekserer Google Søgning den i stedet. Ellers vises siden muligvis slet ikke i Google Søgning.

Næste trin:

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp. En mulig løsning kan være at ændre sidens webadresse for at undgå fejl i almindelige webadresseparsere. Du kan f.eks. prøve at fjerne procentkodede eller reserverede tegn eller usædvanlige kodninger af forespørgselsstrenge, f.eks. ? uden parametre.

Hvis du bruger AMP Packager, kan der være flere årsager:

  • Tjek, at din frontend-reverse-proxy omskriver webadresser korrekt. Det er især sandsynligt, at der opstår problemer i forbindelse med webadresser med procentkodede eller reserverede tegn. For eksempel er der problemer med omskrivningsdirektivet for nginx og den stiløse form af dens proxy_pass-forskrift. Du kan teste dette ved at sende testanmodninger til din frontend og sammenligne dem med de webadresser, som AMP Packager logfører i stdout.
  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du har udelukket alt det ovenstående, kan der være en fejl i AMP Packager. Rapportér en fejl.

Headeren "header_name" i HTTP-svaret for signed exchange-forekomsten har en ugyldig værdi

HTTP-svaret havde indholdstypen application/signed-exchange, men svarheaderne var ugyldige på en anden måde. Det kan f.eks. være, at content-type mangler parameteren v=b3. Formatet er derfor ukendt for Google, og det betyder, at svarteksten ikke kan trækkes ud.

Sådan påvirker det dit website:

Hvis siden har en tilsvarende ikke-AMP-side, indekserer Google Søgning den i stedet. Ellers vises siden muligvis slet ikke i Google Søgning.

Næste trin:

Hvis du bruger en tjenesteudbyder til signed exchange, skal du kontakte udbyderen for at få hjælp.

Hvis du bruger AMP Packager, kan der være flere årsager:

  • Tjek, at din frontend-reverse-proxy ikke ændrer content-type-headere. I forbindelse med den fejlramte webadresse skal du finde frem til den tilsvarende /priv/doc-webadresse på dit interne Packager-domæne og hente den og de tilhørende svarheadere (f.eks. med curl -i). Hvis headerne i det interne Packager-svar og det eksterne frontend-svar er forskellige, kan dette være årsag til fejlen. Hvis forskellen er i en anden header end content-type, skal du rapportere en fejl i denne hjælpedokumentation for at opdatere listen over krav.
  • Tjek, at du kører den nyeste version af AMP Packager.
  • Hvis du har udelukket alt det ovenstående, kan der være en fejl i AMP Packager. Rapportér en fejl.

Prioriter og løs problemer

  1. På oversigtssiden for AMP skal du filtrere advarsler fra, så du kan fokusere på fejl først. Som standard sorteres problemerne efter en kombination af alvorlighed, status for validering og antallet af berørte sider. Vi anbefaler, at du løser dem i denne standardrækkefølge. Start med at rette fejl, der stammer fra samme kilde (f.eks. en skabelon med fejl), og ret derefter fejl, der er unikke for hver side.
  2. Se, om eventuelle stigninger i det samlede antal af fejl primært er forårsaget af en enkelt fejl: Kig efter et tilsvarende udsving i et enkelt problem i tabellen.
  3. Nedenfor kan du se oplysninger om fejlretning i forbindelse med udsving og manglende AMP-sider.
  4. Klik på en række i tabellen for at se infosiden for fejlen:
    1. Infosiden indeholder en eksempelliste over berørte webadresser. Listen viser ikke altid alle resultater, fordi den er begrænset til 1.000 rækker, og den inkluderer muligvis ikke forekomster af denne fejl, der er blevet opdaget for nylig.
    2. Hvis det drejer sig om en syntaksfejl, skal du klikke på Få flere oplysninger for at få officiel dokumentation vedrørende den korrekte syntaks.
    3. Klik på ikonet til undersøgelse for at køre en valideringstest for en berørt side. Denne test lokaliserer alle fejl helt nøjagtigt (ikke kun det aktuelle problem) og den viser websitets kode, fremhæver fejl og giver flere oplysninger. Det er muligt, at en fejl er blevet rettet på livesiden, men stadig er angivet som en fejl på listen, fordi den endnu ikke er blevet crawlet igen. Hvis dette er tilfældet, skal du anmode om validering, efter du har rettet alle forekomster af dette problem.
  5. Løs alle forekomster af problemet på dit website, test din rettelse, og sørg for, at dine rettelser findes på nettet.
  6. Gå tilbage til infosiden for problemet, og klik på knappen Valider rettelse for at starte valideringsprocessen. Denne proces tager et stykke tid. Gå til afsnittet Om validering for at få indblik i valideringsprocessen.
  7. Fortsæt med at rette fejl.
  8. Når alle fejl er rettet, skal du fjerne filteret for advarsler og overveje at rette til, så advarslerne forsvinder. Nogle advarsler drejer sig om manglende valgfri opmærkning af strukturerede data, som kan aktivere nye søgefunktioner for sider med relevant indhold.

Deling af rapporten

Du kan dele oplysninger om problemet i rapporterne om dækning eller forbedring ved at klikke på knappen Del på siden. Dette link giver kun adgang til den aktuelle infoside for problemet samt eventuelle sider med bekræftelseshistorik i forbindelse med problemet for dem, der har linket. Det giver ikke adgang til andre sider for din ressource, og dem, du deler linket med, kan ikke udføre handlinger på din ejendom eller din konto. Du kan til enhver tid tilbagekalde linket ved at deaktivere deling af denne side.

Eksport af rapportdata

Mange rapporter indeholder en eksportknap til eksport af rapportdata. Både diagram- og tabeldata eksporteres.Værdier, der vises som enten ~ eller - i rapporten (ikke tilgængelig/ikke et tal), vil være nul i de downloadede data.

Udsving i fejl

Find ud af, om et udsving er forårsaget af en gruppe sider som følge af ændringer i alvorlighed:

  1. Hvis du kan se en stigning, skal du kigge efter et tilsvarende fald i en anden tilstand (fejl eller gyldig).
  2. Hvis du finder et tilsvarende fald, skal du bekræfte, at de er de samme webadresser.
  3. Hvis webadresserne blev flyttet fra en tilstand til en anden, skal du finde ud af, hvad du har ændret for at forårsage dette.

Den mest almindelige årsag til en pludselig stigning i antallet af fejl er, at en fejl er blevet føjet til en skabelon, der anvendes af mange sider på dit website.

Fejlfinding af manglende AMP-sider

Hvis det samlede antal AMP-sider (gyldig + advarsel + fejl) i rapporten er mindre end antallet af AMP-sider på dit website, skal du gøre følgende:

  • De webadresser, der rapporteres i denne rapport, er et eksempel på alle kendte AMP-webadresser for dit website. Listen med webadresser er derfor ikke udtømmende.
  • Bekræft, at din kanoniske ikke-AMP-side linker korrekt til din AMP-side.
  • Bekræft, at dine AMP-sider eller kanoniske sider ikke blokerer for adgang (via robot.txt eller noindex) eller er beskyttet af krav om godkendelse eller login.
  • Tjek, om dine AMP-sider og kanoniske sider findes i indekset ved at søge efter webadressen til den kanoniske side på Google. Hvis du ikke kan se din kanoniske side, er den ikke indekseret.
    • Hvis du kan se din kanoniske side, skal du bekræfte, at den linker korrekt til din AMP-side.
    • Hvis den kanoniske side ikke fremgår af listen, skal du sende den til indeksering.
  • Linker andre sider til din AMP- eller kanoniske side? Er de angivet i et sitemap? Brug værktøjet til undersøgelse af webadresser på den kanoniske side for at anmode om at indeksere et lille antal AMP-sider. Hvis det drejer sig om mange sider, bør du dog bruge sitemaps (du skal kun angive den kanoniske side i sitemappet). Overvej at bruge rapporten Sitemaps til at indsende et sitemap.
  • Der kan gå et par dage, før Google finder og crawler de manglende sider. Det afhænger af, hvordan du underretter Google om de nye sider.
  • Nogle gyldige AMP-sider medtages muligvis ikke i denne rapport, selvom de kan være angivet i rapporten om indekseringsgrad. Dette skyldes, at rapporten Dækning af indeks skal være mere omfattende for at hjælpe dig med at fejlrette problemer med indeksering i din rapport, mens rapporten for AMP-status potentielt dækker færre, men mere relevante sider, men mere detaljeret for at hjælpe dig med at fejlrette bestemte AMP-problemer på dit website. Du kan bekræfte, om en AMP-side er indekseret, ved at bruge værktøjet til undersøgelse af webadresser, der giver dig det endelige svar.

Om advarsler

AMP-sider med advarsler er indekserede og kan vises i Googles søgeresultater, men vises muligvis ikke med alle tilgængelige AMP-funktioner (som f.eks. at blive vist i en karrusel for Tophistorier). Med andre ord kan disse sider muligvis kun vises som et simpelt søgeresultat med blåt link.

Om validering

Når du har rettet alle forekomster af et specifikt problem på dit website, kan du bede Google om at validere dine ændringer. Hvis alle kendte forekomster er fjernet, markeres problemet som løst i statustabellen og flyttes ned i bunden af tabellen. Search Console registrerer valideringsstatus for problemet som helhed såvel som status for hver forekomst af problemet. Når alle forekomster af problemet er fjernet, anses problemet for løst. Gå til Valideringsstatus for problemer og Valideringsstatus for forekomster for at se de faktisk registrerede statusser.

Mere om problemets levetid...

Et problems levetid strækker sig fra første gang, en forekomst af det pågældende problem blev registreret på dit website, indtil 90 dage efter, at den sidste forekomst blev markeret som fjernet fra dit website. Hvis der går 90 dage, uden at problemet vender tilbage, fjernes det fra rapporthistorikken.

Datoen for første registrering af problemet er den første gang, problemet blev registreret i løbet af problemets levetid, og denne dato ændres ikke. Det betyder følgende:

  • Hvis alle forekomster af et problem er rettet, men en ny forekomst af problemet opstår 15 dage senere, markeres problemet som åbent, og datoen for første registrering forbliver den oprindelige dato.
  • Hvis det samme problem opstår 91 dage efter, at sidste forekomst blev rettet, er det tidligere problem blevet lukket, og derfor registreres det som et nyt problem, hvor datoen for første registrering angives som "i dag".

Grundlæggende valideringsproces

Her er et overblik over valideringsprocessen, efter at du har klikket på Valider rettelse for et problem. Denne proces kan tage flere dage, og du vil modtage notifikationer om processen via mail.

  1. Når du klikker på Valider rettelse, tjekker Search Console et par sider med det samme
    • Hvis den aktuelle forekomst findes på en af disse sider, afsluttes valideringen, og valideringsstatussen forbliver uændret.
    • Hvis eksempelsiderne ikke har den aktuelle fejl, fortsætter valideringen med statussen Startet. Hvis valideringen registrerer andre ikke-relaterede problemer, tælles disse problemer med i den anden problemtype, og valideringen fortsætter.
  2. Search Console arbejder sig gennem listen over kendte webadresser, der er berørt af dette problem. Kun webadresser med kendte forekomster af det pågældende problem sættes i kø til en ny crawl, ikke hele websitet. Search Console registrerer alle webadresser, der tjekkes, i valideringshistorikken, som kan ses via siden med oplysninger om problemet.
  3. Når en webadresse tjekkes:
    1. Hvis der ikke kan findes forekomster af problemet, ændres valideringsstatussen for forekomsten til Ingen overtrædelser. Hvis det drejer sig om første forekomst, der tjekkes, efter valideringen er startet, ændres valideringsstatussen for problemet til Det ser godt ud.
    2. Hvis webadressen ikke længere er tilgængelig, ændres valideringsstatussen for forekomsten til Andet (hvilket ikke er en fejlstatus).
    3. Hvis forekomsten stadig er til stede, ændres statussen for problemet til Mislykkedes, og valideringen afsluttes. Hvis det drejer sig om en ny side, der er opdaget via normal crawl, anses den for en anden forekomst af det eksisterende problem.
  4. Når alle fejl- og advarselswebadresser er blevet tjekket, og antallet af problemer er 0, ændres status for problemet til Godkendt. Vigtigt! Selv når antallet af berørte sider falder til 0, og status for problemet ændres til Godkendt, vises den oprindelige etiket for alvorlighed stadig (Fejl eller Advarsel).

Selvom du aldrig klikker på "Start validering", kan Google registrere rettede forekomster af et problem. Hvis Google under sin normale crawl registrerer, at alle forekomster af et problem er blevet rettet, ændres status for problemet til "Ikke tilgængelig" på rapporten.

Hvornår anses et problem for at være "løst" for en webadresse eller et element?

Et problem markeres som løst for en webadresse eller et element, når en af følgende betingelser er opfyldt:

  • Når webadressen crawles, og problemet ikke længere findes på siden. Hvis der er tale om en AMP-tagfejl, kan dette betyde, at du enten har rettet tagget, eller at tagget er blevet fjernet (hvis tagget ikke er nødvendigt). Under et valideringsforsøg betragtes det som "godkendt".
  • Hvis siden af en eller anden grund ikke er tilgængelig for Google (siden er fjernet, markeret som noindex, kræver godkendelse osv.), anses problemet som løst for den pågældende webadresse. Under et valideringsforsøg tælles det med i valideringsstatussen "Andet".

Ny validering

Når du klikker på Valider igen for en mislykket validering, starter valideringen forfra for alle forekomster, der mislykkedes, samt eventuelle nye forekomster af det pågældende problem, der blev opdaget ved normal crawl.

Du bør vente, til en valideringscyklus er afsluttet, inden du anmoder om en ny cyklus, også selvom du har løst nogle problemer i den aktuelle cyklus.

Forekomster, der har bestået valideringen (og er markeret som Godkendt) eller ikke længere er tilgængelige (markeret som Andet), tjekkes ikke igen og fjernes fra historikken, når du klikker på Valider igen.

Valideringshistorik

Du kan se status for en valideringsanmodning ved at klikke på linket til valideringsoplysninger på siden med oplysninger om problemet.

Poster på siden med valideringshistorikken grupperes efter webadresse i AMP-rapporten og rapporten for indekseringsstatus. I rapporterne om mobilanvendelighed og udvidede resultater grupperes elementer efter kombinationen af webadresse og struktureret dataelement (hvilket bestemmes af elementets navneværdi). Valideringsstatussen gælder for det specifikke problem, du undersøger. Et problem kan have etiketten "Godkendt" på en side, mens andre problemer kan have etiketten "Mislykket", "Afventer" eller "Andet".

Valideringsstatus for problemer

Der anvendes følgende valideringsstatusser for et givet problem:

  • Ikke startet: Der er én eller flere sider med en forekomst af dette problem, som du aldrig har påbegyndt et valideringsforsøg for. Næste trin:
    1. Klik på problemet for at få oplysninger om fejlen. Undersøg de enkelte sider for at se eksempler på fejlen på livesiden ved hjælp af AMP-testen. Hvis AMP-testen ikke viser fejlen på siden, skyldes det, at du har rettet fejlen på livesiden, efter Google fandt fejlen og genererede denne problemrapport.
    2. Klik på "Få flere oplysninger" på siden med oplysninger for at se detaljer om den regel, der blev overtrådt.
    3. Klik på en række med eksempelwebadresser i tabellen for at få oplysninger om den pågældende fejl.
    4. Ret dine sider, og klik derefter på Valider rettelse for at få Google til at crawle dine sider igen. Google giver dig besked om status for valideringen. Valideringen kan tage alt fra et par dage op til ca. to uger, så vær tålmodig. 
  • Startet:  Du har påbegyndt et valideringsforsøg, og der er endnu ikke fundet nogen tilbageværende forekomster af problemet. Næste trin: Google sender notifikationer, efterhånden som valideringen skrider frem, og vejleder dig om nødvendigt i, hvad du skal gøre.
  • Det ser godt ud: Du har påbegyndt et valideringsforsøg, og alle problemforekomster, der hidtil er tjekket, er blevet rettet. Næste trin: Du behøver ikke at foretage dig noget, men Google sender notifikationer, efterhånden som valideringen skrider frem, og vejleder dig i, hvad du skal gøre.
  • Godkendt: Alle kendte forekomster af problemet er væk (eller den berørte webadresse er ikke længere tilgængelig). Du skal have klikket på "Valider rettelse" for at opnå denne status. Hvis forekomsterne forsvandt, uden at du anmodede om validering, ville statussen skifte til Ikke tilgængelig. Næste trin: Der skal ikke gøres mere.
  • Ikke tilgængelig: Google konstaterede, at problemet var løst på alle webadresser, selvom du aldrig har påbegyndt et valideringsforsøg. Næste trin: Der skal ikke gøres mere.
  • Mislykkedes: Et bestemt antal sider indeholder stadig dette problem, efter du har klikket på "Valider". Næste trin: Ret problemet, og valider igen.

Valideringsstatus for forekomster

Når der er anmodet om validering, tildeles alle forekomster af problemet én af følgende valideringsstatusser:

  • Afventer godkendelse: I kø til validering. Problemforekomsten blev registreret, sidste gang Google foretog en gennemgang.
  • Godkendt: [Ikke tilgængelig i alle rapporter] Google har søgt efter forekomster af problemet, og det findes ikke længere. Denne status kan kun tildeles, hvis du udtrykkeligt klikker på Valider for denne forekomst af problemet.
  • Mislykkedes: Google har søgt efter problemforekomsten, og den findes stadig. Denne status kan kun tildeles, hvis du udtrykkeligt klikker på Valider for denne forekomst af problemet.
  • Andet: [Ikke tilgængelig i alle rapporter] Google kunne ikke åbne den webadresse, der hoster forekomsten, eller (for strukturerede data) kunne ikke længere finde elementet på siden. Svarer til Godkendt.

Bemærk, at den samme webadresse kan have forskellige statusser for forskellige problemer. Hvis en enkelt side f.eks. både har problem X og problem Y, kan problem X have valideringsstatussen Godkendt, og problem Y på samme side kan have valideringsstatussen Afventer.

Kendte problemer

Følgende er kendte problemer i Search Console. Du behøver ikke at rapportere problemerne til os, men du må gerne give os feedback om andre funktioner eller problemer, du opdager. Brug Feedback-mekanismen, der er indbygget i navigationslinjen.

  • Visse problemer har lange navne, der kan være svære at forstå.
  • Der kan være en vis forsinkelse fra det tidspunkt, hvor problemet føjes til grafen, til det tidspunkt, hvor det føjes til tabellen.
  • Hvis der er et stort antal problemer på dit website (uanset om der er aktive forekomster eller ej), viser rapporten kun de første 200 problemer sorteret efter vigtighed.
Var disse oplysninger nyttige?
Hvordan kan vi forbedre siden?