Ett saknat offentligt dokument bör visa en tydlig förklaring och returnera en lämplig HTTP-status, vanligtvis 404. På en Mac kan du kontrollera båda i Chrome, identifiera avvikelsen och ge ditt publiceringssystem en tydlig korrigering.
Det här arbetsflödet är till för dig som underhåller offentliga dokumentsidor: guider, referensanteckningar eller enkla instruktionsblad. Målet är att den begärda adressen, serverns svar och det visade meddelandet ska stämma överens. Alla exempelsökvägar nedan är fiktiva.
Vilket svar bör ett saknat dokument returnera?
Börja med att bestämma vad som ska hända på dokumentets adress. En sida som har flyttats behöver hanteras på ett annat sätt än en sida som inte längre finns. Använd den här beslutstabellen innan du ändrar utformningen av sidan för saknade dokument.
| Dokumentets status | Avsett svar | Vad läsarna bör se |
|---|---|---|
| Det finns på den begärda adressen | 200 OK |
Hela dokumentet |
| Det har en tydlig permanent ersättning | Omdirigering med 301 |
Ersättningsdokumentet på dess nya adress |
| Det kan inte hittas och det finns ingen likvärdig ersättning | 404 Not Found |
En användbar förklaring till att dokumentet saknas |
| Det har tagits bort med avsikt och frånvaron väntas bli permanent | 410 Gone är lämpligt |
En tydlig förklaring till borttagningen och användbar navigering |
HTTP definierar 404 utan att ange om frånvaron är tillfällig eller permanent. Koden 410 gäller en resurs vars otillgänglighet väntas bli permanent; när det är okänt om frånvaron är permanent använder du 404. Dessa betydelser anges i RFC 9110, avsnitt 15.5.5 och 15.5.11.
Google rekommenderar en permanent omdirigering när ett dokument har flyttats eller har en tydlig ersättning. Om det har tagits bort utan en liknande ersättning rekommenderar Google 404 eller 410. Se Googles vägledning för hantering av svar för saknat innehåll.
Anta till exempel att /documents/paper-folding-notes har ersatts av /documents/paper-folding-guide, som innehåller i stort sett likvärdiga instruktioner. Då passar en permanent omdirigering. Om anteckningarna har tagits bort utan ersättning bör den gamla adressen fortfarande ge ett svar om att dokumentet saknas. Du kan erbjuda en länk till en allmän dokumentkatalog på den sidan.
Varför räcker det inte att utforma en övertygande sida för saknade dokument?
En sida kan tydligt säga Document not found samtidigt som servern returnerar 200. Google kallar den här typen av avvikelse en soft 404. En tom sida eller en sida utan huvudinnehåll kan också klassificeras så. Läs Googles förklaring av soft 404-fel.
Statusen är en del av HTTP-svaret och skiljer sig från det förklarande innehållet. Därför räcker det inte att ändra rubriken eller lägga till en stor etikett med 404 för att fastställa svarskoden. Kontrollera själva dokumentbegäran innan du avgör att problemet är löst. RFC 9110 beskriver vilken roll svarskoderna har.
Hur kontrollerar du dokumentsvaret på en Mac?
Använd Chromes inbyggda verktyg för den här kontrollen. Förbered en fungerande dokumentadress och en avsiktligt obefintlig sökväg på samma offentliga webbplats. Den saknade sökvägen kan till exempel vara /documents/missing-paper-example-731. Välj en adress där du vet att inget dokument har publicerats.
- Öppna den offentliga sidan i Chrome.
- Tryck på
Command+Option+Iför att öppna DevTools. - Välj panelen
Network. - Ange testadressen i adressfältet medan DevTools är öppet och läs in den.
Chrome beskriver Mac-genvägen i Öppna Chrome DevTools. Nätverksaktivitet registreras medan DevTools är öppet, vilket förklaras i översikten över panelen Network.
- Välj
Disable cacheså att kontrollen inte förlitar sig på webbläsarens cachade svar. - Aktivera
Preserve logom du behöver följa navigeringen genom omdirigeringar. - Läs in testadressen igen.
- Välj huvudbegäran för dokumentet och öppna sedan
Headers. Läs av begärans adress och statuskoden underGeneral.
Dessa kontroller och var statusinformationen finns dokumenteras i Chromes referens för nätverksfunktioner.
Granska dokumentbegäran noggrant. Loggen innehåller också begäranden för skript, formatmallar och andra resurser. Att en stödfil saknas visar inte att själva dokumentet returnerade 404. Chromes begärandetabell skiljer HTTP-koden i Status från resurskategorin i Type; se Granska nätverksaktivitet.
Jämför nu tre observationer: den ursprungligen begärda adressen, dokumentets svarskod och sidan som visas efter inläsningen. Anteckna dem tillsammans. Om navigeringen ändrar adressen granskar du den ursprungliga begäran och målet, i stället för att bara anteckna den slutliga sidan.
Hur omvandlar du observationerna till en korrigering?
Följande diagnostiktabell är en praktisk sammanställning av HTTP-betydelser och Googles felsökningsvägledning. Den är ett stöd för beslut, inte en uppsättning uppmätta resultat.
| Observerat resultat | Vad du bör undersöka | Avsedd korrigering |
|---|---|---|
200 med ett meddelande om att dokumentet saknas |
Hanteraren för saknade sökvägar eller reservlösningen | Returnera 404 med förklaringen |
404 med det förväntade dokumentet synligt |
Svaret som tilldelats en befintlig sökväg | Visa dokumentet med 200 |
| Omdirigering till en bred katalog | Om det finns en likvärdig ersättning | Omdirigera till det likvärdiga dokumentet eller visa en sida om att det saknas |
200 med ett tomt eller ofullständigt dokument |
Inläsning och återgivning av innehållet | Återställ det avsedda innehållet om dokumentet fortfarande finns |
404 med ett användbart meddelande om att sidan saknas |
Om adressen verkligen saknar ett dokument | Behåll beteendet om frånvaron är avsiktlig |
Googles felsökningsdokumentation skiljer uttryckligen mellan dokument som inte är tillgängliga, dokument som har flyttats och dokument som fortfarande finns men inte läses in korrekt. Skillnaden förhindrar att en ofullständig fungerande sida behandlas som avsiktligt borttagen. Se Felsöka genomsökningsfel i Google Sök.
Skriv följande som en konkret överlämning: ”För den fiktiva sökvägen /documents/missing-paper-example-731 ska systemet returnera 404 och visa den anpassade sidan för saknade dokument på den adressen. Befintliga dokumentsökvägar ska fortsätta fungera. Använd permanenta omdirigeringar endast när en likvärdig ersättning har identifierats.” Lägg till den status och det synliga meddelande du observerade vid kontrollen.
Begäran beskriver det önskade beteendet utan att du behöver gissa namnen på menyerna i publiceringssystemet. Ändringen görs i värdkonfigurationen, programsökvägen eller publiceringssystemet som skapar svaret. Google förklarar att HTTP-statuskoder genereras av värdservern i sin dokumentation om HTTP-statuskoder.
Vad gör du om redigeraren bara låter dig ändra sidinnehåll?
En redigerare som ändrar text eller dokumentmetadata styr kanske inte HTTP-svar. WHATWG HTML Standard definierar specifika beteenden för meta-direktiv med http-equiv; att ange en HTTP-svarstatus ingår inte bland dem. Att lägga till http-equiv="status" är därför inte ett stödd sätt att skapa en 404. Se HTML Standard: Pragma-direktiv.
Om redigeraren saknar inställningar för svar använder du värd- eller programlagrets dokumenterade funktion för saknade sidor. Fråga om den visar det anpassade innehållet med 404 på den begärda adressen till det saknade dokumentet. En inställning som bara väljer en layout för felsidor besvarar inte den frågan; kontrollera resultatet med webbläsarflödet.
Ett dokumenterat exempel för statiska sidor på Netlify
För en befintlig statisk webbplats på Netlify är den dokumenterade metoden en fil med namnet 404.html. Netlify använder den automatiskt för sökvägar som inte leder till någon statisk fil. Det här är ett leverantörsspecifikt exempel med förutsättningar: du behöver åtkomst till webbplatsens färdiga utdata och en befintlig byggprocess för statiska sidor. Netlify dokumenterar anpassad 404-hantering.
- Använd webbplatsens befintliga sidmall för att skapa sidan för saknade dokument.
- Se till att den färdiga utdatauppsättningen innehåller
404.htmli publiceringskatalogens rot. - Kontrollera att ingen tidigare omdirigeringsregel skickar okända adresser till en annan sida.
- När den uppdaterade utdatauppsättningen finns på den offentliga adressen kontrollerar du både en saknad sökväg och ett fungerande dokument.
Kontrollen av omdirigeringen är viktig eftersom Netlify behandlar omdirigeringar innan de går vidare till statiska filer och den slutliga hanteringen av saknade sidor. En begäran som hanteras tidigare når inte den slutliga hanteraren. I dokumentationen om Request Chain förklaras ordningen. Exemplet beskriver hur en korrigering kan gå till; det innebär inte att någon webbplats har ändrats.
Begränsningar för program som hanterar navigering i webbläsaren
Vissa program upptäcker att ett dokument saknas först efter att JavaScript har körts. Google medger att det kan vara opraktiskt att använda meningsfulla statuskoder vid klientbaserad navigering. Alternativen som Google dokumenterar är en JavaScript-omdirigering till en adress vars server returnerar 404, eller att lägga till metadata med noindex på felsidan. Se Googles vägledning om JavaScript och SEO.
Dessa alternativ ger olika resultat. Omdirigeringen går till en ny adress med ett verkligt svar för en saknad sida. Metoden med metadata påverkar indexeringen, men lämnar den ursprungliga HTTP-statusen oförändrad. Om kravet är att behålla den ursprungliga dokumentadressen och returnera 404 där måste värd- eller programsvaret ha stöd för det.
Vad bör sidan för saknade dokument säga?
Använd ett kort, tydligt meddelande, till exempel Det gick inte att hitta det här dokumentet. Följ upp med en användbar åtgärd: en länk till dokumentkatalogen eller en annan verifierad navigeringsdestination. Behåll webbplatsens välbekanta navigering och utseende. Google rekommenderar tydligt språk, en enhetlig utformning och användbara länkar på anpassade sidor för saknade dokument.
För det fiktiva exemplet med pappersvikning skulle en lämplig text vara: Vi kunde inte hitta det här dokumentet om pappersvikning. Bläddra i dokumentkatalogen för att välja en annan guide. Beskriv ett dokument som permanent borttaget endast när du vet att det stämmer. Visa förklaringen tydligt i stället för att genast skicka alla saknade adresser vidare.
Hur verifierar du att svaret och sidan stämmer överens?
Upprepa kontrollen med ett litet jämförelseurval. De förväntade resultaten nedan är exempel på godkännandekriterier; de är inte rapporterade testresultat.
| Testfall | Förväntat svar och sida |
|---|---|
| Känt fungerande dokument | 200, med hela dokumentet |
| Avsiktligt obefintlig sökväg | 404, med en förklaring till att dokumentet saknas |
| Borttaget dokument utan ersättning | 404, eller 410 när det är lämpligt, med en korrekt förklaring |
| Flyttat dokument med en likvärdig ersättning | Permanent omdirigering, följd av ersättningens fungerande svar |
Testa igen genom att ange varje adress direkt och läsa in den på nytt. Ta även med dokument som vanligtvis nås via navigering på sidan. Då kontrollerar du vilket svar en ny dokumentbegäran får. Håll ihop adressen, koden och det synliga resultatet så att en fungerande målsida inte döljer ett felaktigt svar tidigare i navigeringen.
Om ett gammalt resultat ligger kvar skiljer du mellan webbläsarens cache och andra cachar. Om du inaktiverar Chromes cache påverkar det webbläsarens cache. HTTP-cachelagring kan också lagra negativa svar som 404, så om ett inaktuellt svar om att dokumentet saknas visas kan du behöva kontrollera publiceringssystemets dokumenterade cachebeteende. RFC 9111 förklarar cachelagringsbara negativa resultat.
För Google Sök får ett verkligt svar om att dokumentet saknas en avsedd följd: Google indexerar inte URL:er som returnerar 404 eller 410, och tidigare indexerade URL:er tas bort när dessa svar behandlas. Ett lyckat svar med 200 garanterar inte heller indexering. Se Så påverkar HTTP-statuskoder Googles sökrobotar.
Avsluta när varje testad adress ger en konsekvent bild: tillgängliga dokument läses in korrekt, flyttade dokument leder till sina ersättningar och saknade dokument returnerar ett lämpligt svar med användbar navigering. Då har du en konkret, repeterbar publiceringskontroll på din Mac.
Källor
- RFC 9110: HTTP Semantics — RFC Editor
- RFC 9111: HTTP Caching — RFC Editor
- HTML Standard: Pragma directives — WHATWG
- Felsöka genomsökningsfel i Google Sök — Google Search Central
- Så påverkar HTTP-statuskoder Googles sökrobotar — Google for Developers
- Förstå grunderna i JavaScript-SEO — Google Search Central
- Öppna Chrome DevTools — Chrome for Developers
- Panelen Network: Analysera nätverksinläsning och resurser — Chrome for Developers
- Referens för nätverksfunktioner — Chrome for Developers
- Granska nätverksaktivitet — Chrome for Developers
- Omdirigeringsalternativ — Netlify
- Request Chain — Netlify