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 de kritiske problemer, der påvirker AMP-siderne på dit website. Klik på et bestemt problem for at se de sider, der er berørt af problemet, og oplysninger om problemet.

ÅBN AMP-RAPPORTEN

 

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

 

Dette indeholder rapporten

Kritiske problemer: Sider, der er berørt af kritiske AMP-problemer, kan ikke vises på Google. En liste over kritiske problemer, der blev fundet på dit website, vises direkte under diagrammet på den overordnede side i AMP-rapporten med titlen Derfor er AMP-siderne ugyldige. Klik på et problem på listen for at se de sider, der har det valgte problem.

Ikke-kritiske problemer (advarsler): AMP-sider med ikke-kritiske problemer kan stadig blive vist på Google, så længe de ikke også har kritiske problemer. En liste over ikke-kritiske problemer, der blev fundet på dit website, vises under listen over kritiske problemer på den overordnede side i AMP-rapporten med titlen Ikke-kritiske problemer. Klik på et problem på listen for at se de sider, der har det valgte problem. AMP-sider med advarsler vises muligvis ikke med alle tilgængelige AMP-funktioner (som f.eks. omfatter visning i en karrusel for Tophistorier). Med andre ord kan disse sider muligvis kun vises som et simpelt søgeresultat med blåt link.

Sidestatus (gyldige og ugyldige sider): AMP-sider er enten gyldige eller ugyldige. Gyldige AMP-sider kan vises på Google, mens ugyldige AMP-sider ikke kan vises på Google. Hvis der er kritiske problemer på en side, betragtes siden som ugyldig. Hvis siden kun har advarsler eller slet ikke har nogen problemer, betragtes den som gyldig. Du kan se en liste over gyldige AMP-sider ved at klikke på Se data om gyldige AMP-sider under diagrammet på den overordnede side i AMP-rapporten.

Kig efter følgende

Du skal sigte efter følgende tal i din rapport:

  • Nul kritiske problemer på dit website. Se anbefalinger til, hvordan du retter fejl, under Prioriter og løs problemer.
  • Det samlede antal AMP-sider i rapporten (gyldige og ugyldige sider) bør stemme nogenlunde overens med antallet af AMP-sider på dit website. Hvis det ikke er tilfældet, skal du gå til Fejlfinding af manglende AMP-sider.

Listen over berørte webadresser er et eksempel, men det er ikke sikkert, at den omfatter alle de webadresser, der er berørt af et givent problem. Rapporten er begrænset til 1.000 webadresser pr. problem. Det er også muligt, at der findes yderligere sider, som vi af ukendte årsager ikke har registreret eller talt.

Rapporten kan kun vise 200 kritiske og ikke-kritiske problemer i alt. Hvis dit website har en meget lang liste over problemer (uanset om der er aktive forekomster eller ej), viser rapporten kun de 200 vigtigste problemer sorteret efter vigtighed.

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. Hvis du ikke ønsker dette, kan du teste din robots.txt-fil for blokeringsreglen og derefter ændre eller fjerne reglen (eller bede din webudvikler om at gøre det for dig).
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.
Et modulscript er angivet uden et alternativ for manglende modul (eller omvendt) Du bruger enten et <script type="module">-tag uden et matchende <script nomodule async>-tag eller omvendt. Disse tags skal bruges i matchende par for at muliggøre korrekt håndtering af browsere, der understøtter modulscripts, eller som ikke gør.
Manglende webadresse i HTML-tag Det angivne HTML-tag kræver en attribut med en gyldig webadresse, som har en længde, der ikke er nul, men hvor webadressen er en tom streng. Angiv en gyldig webadresse for den fremhævede attribut.
Attributten mangler eller er forkert, men den er obligatorisk i henhold til attributten "on". Den angivne attribut er obligatorisk, men den er forkert eller mangler. Denne attribut er obligatorisk, fordi du har angivet en "on"-attribut i det samme tag.
Underordnet <svg>-tag fundet uden for en <svg>-blok. Du har angivet et tag uden for en <svg>-blok, som skal være indlejret i en <svg>-blok.
Siden indlæser flere forskellige versioner af det samme udvidelsescript Siden indlæser flere versioner af den samme AMP-udvidelse. Du kan løse problemet ved at fjerne én version af scriptet.
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 får du vist Signed HTTP Exchange-oplysninger om et problem

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 skal 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 (brug enten værktøjet til undersøgelse af webadresser til at undersøge en bestemt webadresse, eller klik på undersøgelsesikonet 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.

Prøv følgende vejledning til at finde og rette fejlen:

  • 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 HTTP 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. Se listen over kritiske problemer for dit website i tabellen Derfor er AMP-siderne ugyldige.
  2. Analysér dine fejl:
    • 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.
    • 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.
  3. Ret dine fejl: Klik på en række i tabellen for at se infosiden for fejlen:
    1. Infosiden indeholder en eksempelliste over berørte webadresser. Listen er begrænset til 1.000 rækker og omfatter muligvis ikke forekomster af denne fejl, der er registreret for nylig, eller sider, der ikke er blevet crawlet igen, siden fejlen opstod.
    2. Klik på Få flere oplysninger ud for et problem for at få officiel dokumentation om fejlen.
    3. Klik på en webadresse i tabellen med eksempelwebadresser for at se problemet fremhævet i sidekoden.
    4. Klik på undersøgelsesikonet for at køre en detaljeret test af en bestemt 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. Hvis siden ikke er blevet crawlet igen for nylig, vises problemet for den indekserede side, men ikke for livesiden. Hvis det er tilfældet, kan du anmode om indeksering af den pågældende side.
    5. Løs alle forekomster af problemet på dit website, test din rettelse, og sørg for, at dine rettelser findes på nettet.
  4. Når du har løst alle forekomster, skal du gå tilbage til problemets infoside og klikke 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.
  5. Fortsæt med at rette fejl.
  6. Hvis det samlede antal gyldige og ugyldige sider er betydeligt lavere end antallet af AMP-sider på dit website, skal du gå til Fejlfinding af manglende AMP-sider.
  7. Når alle kritiske fejl er rettet, bør du overveje at løse de ikke-kritiske problemer. Nogle ikke-kritiske problemer (f.eks. brug af udfasede funktioner) kan blive kritiske på et senere tidspunkt.

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.

Fejlfinding af manglende AMP-sider

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

  • 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 login.
  • Undersøg den kanoniske webadresse for din AMP-side for at se, om den er 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.
  • 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 Sideindeksering. Dette skyldes, at rapporten Sideindeksering 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 tjekke, om en AMP-side er indekseret, ved at bruge værktøjet til undersøgelse af webadresser, der giver dig det endelige svar.
Valider dine rettelser

Når du har rettet alle forekomster af et specifikt problem på dit website, kan du bede Google om at bekræfte dine rettelser. Hvis alle kendte forekomster er rettet, angives antallet som nul i tabellen med problemer og flyttes ned i bunden af tabellen.

Hvorfor skal du validere?

Hvis du fortæller Google, at du har løst alle problemer med en bestemt problemstatus eller -kategori, har det følgende fordele:

  • Du får en mail, når Google har bekræftet din rettelse på alle webadresser, eller omvendt, hvis Google har fundet resterende forekomster af det pågældende problem.
  • Du kan følge Googles fremgang i forbindelse med bekræftelse af dine rettelser og se en logfil med alle sider, der er sat i kø til at blive tjekket, og tjekke status for rettelse af hver webadresse.

Det er muligvis ikke altid en god idé at løse og validere et bestemt problem på dit website. Webadresser, der er blokeret af robots.txt, er f.eks. sandsynligvis blokeret med vilje. Brug din dømmekraft, når du beslutter, om du vil løse et bestemt problem.

Du kan også løse problemer uden at validere. Google opdaterer antallet af forekomster, når en side med kendte problemer crawles, uanset om du udtrykkeligt har anmodet om validering af rettelsen.

Eksperttip! Valider dine rettelser efter sitemap
Du kan fremskynde en anmodning om rettelse ved at oprette og indsende et sitemap, der kun indeholder dine vigtigste sider, og derefter filtrere rapporten efter det pågældende sitemap, før du anmoder om validering af rettelsen. En anmodning om validering i forhold til en undergruppe af dine berørte webadresser kan udføres hurtigere end en anmodning, der omfatter alle berørte webadresser på dit website.

Start validering

Sådan fortæller du Search Console, at du har løst et problem:

  1. Løs alle forekomster af problemet på dit website. Hvis du overser en rettelse, stopper valideringen, når Google finder en enkelt resterende forekomst af det pågældende problem.
  2. Åbn infosiden for det problem, som du har løst. Klik på problemet på listen over problemer i din rapport.
    • ⚠️ Hvis der er filtreret efter et bestemt sitemap i din rapport, gælder valideringen kun for elementer i sitemappet på det tidspunkt, du anmodede om valideringen. Det kan godt være, at det er sådan, du vil have det, men måske ikke. Du skal bare være opmærksom på det.
  3. Klik på Valider rettelse. Klik ikke på Valider rettelse igen, før valideringen er lykkedes eller mislykket. Få flere oplysninger om, hvordan Google tjekker dine rettelser.
  4. Du kan holde øje med status for validering. Valideringen tager typisk op til to uger, men i nogle tilfælde kan der gå meget længere tid, så vær tålmodig. Du modtager en notifikation, når valideringen er lykkedes eller mislykket.
  5. Hvis valideringen er mislykket, kan du se, hvilken webadresse der har forårsaget dette, ved at klikke på Se info på infosiden for problemet. Løs problemet med denne side, bekræft din rettelse på alle webadresser i tilstanden Afventer, og genstart validering.

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 får den etiketten 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 kategoriseres det under valideringsstatussen Andet.

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 tabellen over problemer.

Datoen for første registrering af et problem 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 den seneste forekomst blev løst, er det tidligere problem blevet lukket, og derfor registreres det som et nyt problem, hvor datoen for første registrering angives som datoen for den nye registrering.
Valideringsproces

Her er et overblik over valideringsprocessen, efter at du har klikket på Valider rettelse for et problem. Denne proces kan tage flere dage eller endnu længere, og du modtager notifikationer om processen via mail.

  1. Når du klikker på Valider rettelse, tjekker Search Console straks nogle få sider.
    • 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 er tjekket:
    1. Hvis problemet ikke findes, æ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 webadresser, der er sat i kø, er blevet tjekket i forhold til dette problem, og problemet med dem anses som løst, ændres status for problemet til Godkendt. Når alle forekomster af problemet er blevet rettet, ændres alvorsgraden for problemet dog ikke (Fejl eller Advarsel), men kun antallet af berørte elementer (0).

Selvom du aldrig klikker på Start validering, kan Google registrere rettede forekomster af et problem. Hvis Google under den normale crawl registrerer, at alle forekomster af et problem er blevet løst, ændres antallet af problemer til 0 i rapporten.

Ny validering

⚠️ Vent, til en valideringscyklus er afsluttet, inden du anmoder om en ny cyklus, også selvom du har løst nogle problemer i den aktuelle cyklus.

Sådan genstarter du en mislykket validering:

  1. Gå til valideringsloggen for den mislykkede validering: Gå til infosiden for det problem, der mislykkedes, og klik på Se info.
  2. Klik på Start en ny godkendelse.
  3. Valideringen genstarter for alle webadresser, der er markeret som Afventer eller Mislykkedes, samt for alle nye forekomster af dette problem, der blev opdaget under den normale crawl, siden sidste valideringsforsøg. Webadresser, der er markeret som Godkendt eller Andet, tjekkes ikke igen.
  4. Valideringen tager typisk op til to uger, men i nogle tilfælde kan der gå meget længere tid, så vær tålmodig.

Se valideringsstatus

Sådan kan du se statussen for en aktuel valideringsanmodning eller historikken for den seneste anmodning, hvis en validering ikke er i gang:

  1. Åbn infosiden for problemet. Klik på rækken med problemer på hovedsiden for rapporten for at åbne infosiden for problemet.
  2. Klik på Få flere oplysninger for at åbne infosiden for valideringen for den pågældende anmodning.
    • Forekomststatussen for hver webadresse, der medtages i anmodningen, vises i tabellen.
    • Forekomststatussen gælder for det specifikke problem, du undersøger. Du kan have et problem med etiketten Godkendt på en side, men andre problemer med etiketten Mislykkedes, Afventer eller Andet på den samme side.
    • I AMP-rapporten og rapporten Sideindeksering grupperes posterne på siden over valideringshistorik efter webadresse.
    • I rapporterne om mobilanvendelighed og udvidede resultater grupperes elementer efter kombinationen af webadresse og element med strukturerede data (hvilket bestemmes af elementets navneværdi).
Status for valideringsanmodning

Følgende valideringsstatusser gælder for valideringen for et givet problem:

  • Ikke startet: Én eller flere forekomster af dette problem har aldrig været medtaget i en valideringsanmodning for dette problem.
    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.
    2. Klik på Få flere oplysninger på infosiden for at se detaljerede oplysninger om problemet.
    3. Klik på en række med eksempelwebadresser i tabellen for at få oplysninger om den pågældende fejl.
    4. Løs problemerne med dine sider, og klik derefter på Valider rettelse for at starte valideringen. Valideringen tager typisk op til to uger, men i nogle tilfælde kan der gå meget længere tid, så vær tålmodig.
  • Startet: Du har påbegyndt et valideringsforsøg, og der er endnu ikke fundet 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 forsvinder, uden at du anmoder om validering, skifter statussen 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 har stadig dette problem, efter du har klikket på Valider.
    Næste trin: Løs problemet, og genstart valideringen.
Valideringsstatus for forekomster

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

  • Afventer: I kø til validering. Problemforekomsten fandtes, sidste gang Google kiggede.
  • 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! 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.

Var disse oplysninger nyttige?

Hvordan kan vi forbedre siden?

Har du brug for mere hjælp?

Prøv følgende næste trin:

Opret et opslag i hjælpegruppen Få svar fra medlemmer af hjælpegruppen
true
Nye til Search Console?

Er det første gang, du bruger Search Console? Start her, uanset om du er en nybegynder, SEO-ekspert eller websiteudvikler.

Søgning
Ryd søgning
Luk søgning
Hovedmenu
9199206723499598104
true
Søg i Hjælp
true
true
true
true
true
83844
false
false