We hebben een nieuw boek uitgebracht, Social Media Content Marketing: hoe u in de hoofden van uw volgers kunt kruipen en ze verliefd kunt maken op uw merk.
Robots communiceren met elkaar. Niet alleen in de blockbusters in Japan of Hollywood, maar nu, terwijl je dit artikel leest. Alleen hun communicatietaal is specifiek, en u moet deze begrijpen als u wilt weten hoe u het werk kunt organiseren om de site te verbeteren. Om dit te doen, moet u statuscodes bestuderen. Om je te helpen bij het navigeren door de grammatica, hebben we vanuit Yoast de basisbeginselen vertaald.
HTTP-statuscodes zoals 404, 301 en , zijn voor gebruikers nauwelijks van belang, maar voor SEO's zijn ze ongelooflijk belangrijk. Bots van zoekmachines (zoals Googlebot) gebruiken ze niet alleen om de gezondheid van een site te bepalen, statuscodes helpen ook te vertellen wat er gaande is tussen de browser en de server. Sommigen geven een fout aan, zoals een signaal dat de gevraagde inhoud niet kan worden gevonden, terwijl anderen eenvoudigweg het gevraagde materiaal uitvoeren. In dit artikel gaan we dieper in op de belangrijkste HTTP-headercodes en wat deze betekenen voor SEO.
Wat zijn HTTP-statuscodes en waarom zie je ze?
Een HTTP-statuscode is een bericht dat door de server wordt verzonden bij het verzenden van een verzoek vanuit een browser, waarin wordt aangegeven of het verzoek kan worden voltooid of niet. Volgens de officiële W3C-specificatie zijn er tientallen statuscodes, waarvan je er vele waarschijnlijk niet zult tegenkomen. En als je een volledig overzicht van mogelijke opties tegenkomt, kun je kijken op HTTPstatuses.com.
Om deze codes te begrijpen, moet u weten hoe de browser de webpagina ontvangt.
De gebruiker kan op twee manieren naar de website gaan: door de site-URL te typen of door een zoekopdracht in de zoekbalk in te voeren. De browser stuurt vervolgens een verzoek naar het IP-adres van de site om de bijbehorende webpagina op te halen. De server reageert op de browser door een statuscode te verzenden die is ingebed in de HTTP-header. Als alles in orde is, wordt de HTTP 200-headercode samen met de gevraagde inhoud teruggestuurd naar de browser.
Het kan echter zijn dat er iets mis is met de opgevraagde inhoud of server. De pagina kan bijvoorbeeld niet worden gevonden (wat een 404-foutcode retourneert), of er is een tijdelijk technisch probleem met de server, wat resulteert in een 500-interne serverfoutcode. Deze HTTP-statuscodes zijn belangrijke hulpmiddelen voor het beoordelen van de gezondheid van een site en zijn server. Als een site regelmatig onjuiste HTTP-headercodes naar de zoekmachine stuurt, wordt de inhoud ervan niet geïndexeerd, wat op zijn beurt de ranking zal schaden.
Diverse klassen
Er zijn vijf klassen van HTTP-statuscodebereiken die de verschillende soorten processen definiëren die plaatsvinden tussen de client en de server. Ze zien er zo uit:
- 1xx – Over iets informeren.
- 2xx – Succes rapporteren.
- 3xx – Omleidingsmeldingen.
- 4xx – Rapporteren van een clientfout.
- 5xx – Rapporteren van een serverfout.
De belangrijkste HTTP-statuscodes voor SEO
Zoals we al zeiden, is de lijst met codes lang, maar er zijn er een paar die vooral belangrijk zijn voor optimizers en voor degenen die zelfstandig met hun site werken. Laten we een korte lijst maken die u beter zou moeten kennen dan de tafel van vermenigvuldiging:
200: OK / Succes
Zo zou het moeten zijn: de client vraagt om inhoud van de server en de server antwoordt met een 200-bericht. Dit betekent dat het verzoek succesvol was: de browser ontvangt inhoud die aan de behoeften van de klant voldoet. Zowel de server als de client zijn tevreden. De gebruiker is blij. Alle 2xx-klasseberichten geven de succesvolle voltooiing van een bepaalde bewerking aan.
301: permanent verplaatst
De HTTP 301-header wordt gebruikt wanneer de opgevraagde URL naar een nieuwe locatie is verplaatst. Omdat u met de site werkt, zult u vaak met de code te maken krijgen - om de oude URL naar de nieuwe om te leiden, moet u zeker een 301-omleiding uitvoeren. Als u dit niet doet, zien gebruikers een pagina met een foutcode (404) wanneer ze de oude URL openen.
302: gevonden
HTTP-statuscode 302 betekent dat de doelinhoud is gevonden, maar zich op een andere locatie bevindt. Dit is een nogal dubbelzinnige statuscode: er staat niet in of dit een tijdelijke situatie is of niet. Gebruik alleen een 302-redirect als je de URL tijdelijk wilt doorverwijzen naar een andere bron en je er zeker van bent dat je de URL opnieuw gaat gebruiken. Met deze code vertel je zoekmachines dat de URL zal worden gebruikt, wat betekent dat de linkjuice niet wordt overgedragen naar de nieuwe URL. Gebruik daarom geen 302-redirect bij het verhuizen van een domein of het aanbrengen van grote wijzigingen in de sitestructuur.
307: Tijdelijke omleiding
De statuscode 307 vervangt 302 in de HTTP1.1-specificatie en kan worden beschouwd als de enige echte omleiding. U kunt 307 gebruiken als u de URL tijdelijk naar een nieuwe wilt omleiden, waarbij de oorspronkelijke verzoekmethode ongewijzigd blijft. 307 lijkt op 302, behalve dat het specifiek het tijdelijke karakter van de nieuwe locatie communiceert. Het verzoek kan in de loop van de tijd veranderen, dus de client moet de oorspronkelijke URL blijven gebruiken bij het indienen van nieuwe verzoeken.
403: Verboden
403 vertelt de browser dat de gevraagde inhoud niet is toegestaan voor de gebruiker. Als de gebruiker er niet in slaagt de juiste inloggegevens op te geven, blijft de inhoud niet beschikbaar.
404: Niet gevonden
De HTTP 404-headercode is een van de belangrijkste. Wanneer de server reageert met een 404-fout, wordt u geïnformeerd dat de inhoud niet is gevonden en waarschijnlijk is verwijderd. Probeer bezoekers niet te irriteren met berichten met deze code, herstel fouten zo snel mogelijk. Gebruik een omleiding om sitebezoekers om te leiden van een oude URL naar een nieuw artikel of een nieuwe pagina met gerelateerde inhoud.
Monitor 404-berichten in de Crawlfouten-interface van Google Search Console en probeer het aantal tot een minimum te beperken. Een groot aantal van dit soort fouten kan door Google worden beschouwd als een teken van slechte service, en dit heeft invloed op de ranking van de site.
410: verwijderd
Het resultaat van een 410-code is hetzelfde als een 404: er is geen inhoud gevonden. Met 410 vertel je zoekmachines echter dat ze de gevraagde inhoud moeten verwijderen. Deze code is dus veel specifieker dan 404. In zekere zin vertel je de zoekmachine dat hij de URL uit de index moet verwijderen. Voordat u iets definitief van een site verwijdert, moet u overwegen of er ergens een gelijkwaardige pagina bestaat. Zo ja, omleiden. Als dit niet het geval is, moet de pagina worden verwijderd of verbeterd.
451: Informatie niet beschikbaar vanwege juridische redenen
Een relatief nieuwe toevoeging. HTTP-statuscode 451 geeft aan dat de opgevraagde inhoud om juridische redenen is verwijderd. Als u een verwijderingsverzoek ontvangt, moet u deze code gebruiken om zoekmachines te vertellen wat er met de pagina is gebeurd.
500: Interne serverfout
Fout 500 is een bericht dat de server een voorwaarde heeft aangetroffen waardoor het verzoek niet kan worden voltooid, zonder aan te geven waardoor dit wordt veroorzaakt. Fouten kunnen door van alles worden veroorzaakt, zoals een defect script op uw site. Controleer de serverlogboeken om te zien waar de problemen zitten.
503: Dienst niet beschikbaar
De server stuurt een bericht wanneer hij door een storing of overbelasting een verzoek niet kan verwerken. Gebruik deze code wanneer u tijdelijke downtime nodig heeft, bijvoorbeeld wanneer u website-onderhoud uitvoert. Op deze manier weten de crawlers van zoekmachines dat uw site binnenkort weer online zal zijn, en kunnen ze later terugkomen.
Werken met HTTP-statuscodes
HTTP-codes vormen een belangrijk onderdeel van het werk van optimizers. Je zult ze dagelijks tegenkomen. Daarom is het belangrijk om te begrijpen wat de verschillende codes betekenen. Wanneer u bijvoorbeeld een pagina van een site verwijdert, is het belangrijk om het verschil te kennen tussen een 301- en een 410-omleiding. Ze dienen verschillende doeleinden en leiden daarom tot verschillende resultaten.
Als u een idee wilt krijgen van de soorten statuscodes die uw site genereert, logt u in op Google Search Console. Hier vindt u een pagina met crawlfouten. Ze moeten worden gevonden en geëlimineerd voordat uw site kan worden geïndexeerd.
Tot slot
Onthoud deze codes, als u met de site werkt, ziet u hoe vaak ze verschijnen. Als u weet welke omleidingen u in een bepaalde situatie moet gebruiken, kunt u uw site behoeden voor onnodige verliezen op rankingposities. Eén blik op crawlfouten in Google Search Console zou voldoende moeten zijn om u een redelijk goed beeld te geven van wat er onder de motorkap gebeurt.
Irina Vinnitsjenko
Contentmarketeer SEMANTICA
De eigenaar van de site is een moderne Michelangelo. Hij heeft het vormloze materiaal, het doel en misschien wel de smaak en vaardigheid om het project uit te voeren. Maar de site-eigenaar heeft ook iets dat de beeldhouwers niet hadden: Google Search Console, waarmee je fouten tijdig kunt vinden en elimineren.
Hoe dit te doen? Open Google Search Console. Ga naar de " Crawl > Crawlfouten. Daar kunt u zien wat er met de site gebeurt en problemen oplossen.
Allereerst moet u rekening houden met externe links die naar de pagina leiden. Google heeft de neiging fouten te sorteren op belangrijkheid. Fouten met externe links worden met prioriteit behandeld. Om te zien waar de link vandaan komt, klikt u op de 404-pagina-URL. Selecteer op het geopende tabblad 'Gekoppeld van' en bekijk de URL-links naar de pagina. Zorg ervoor dat alle 404-pagina’s worden doorgestuurd met een 301-redirect naar de relevante URL.
U moet uw site vaak op fouten controleren. Doe dit minstens één keer per maand.
De HTTP 404-code is vooral belangrijk omdat gebruikers deze het vaakst zien. Het is uw doel om de beste gebruikerservaring te bieden, dus zorg ervoor dat u de pagina correct opmaakt met deze code.
Het moet het volgende bevatten:
- Melding dat de gebruiker een pagina heeft geopend die niet bestaat.
- Zoekvenster.
- Eenvoudige navigatie waarmee de gebruiker toegang krijgt tot wat hij zocht.
- Link naar startpagina.
Bovendien is het beter om de pagina visueel te ontwerpen. Een ongebruikelijk ontwerp zorgt ervoor dat gebruikers op de site blijven. over hoe je het correct en mooi kunt doen
De HTTP-statuscode is gecodeerd in 3 cijfers. Het eerste cijfer geeft de conditieklasse (codegroep) aan. Het tweede en derde cijfer zijn het serienummer van de responscode.
De HTTP-statuscode wordt geretourneerd door de server. Het maakt deel uit van de eerste regel van het serverantwoord voor HTTP-verzoeken en geeft aan of een bepaald HTTP-verzoek met succes is voltooid.
De codes zijn gegroepeerd in 5 klassen: informatief (1xx), succes (2xx), omleidingen (3xx), clientfouten (4xx) en serverfouten (5xx).
Korte beschrijving van de lessen:
- 1xx (informatief): deze klasse bevat codes die informatie geven over het overdrachtsproces
- 2xx (succesvol): berichten van deze klasse informeren over gevallen van succesvolle acceptatie en verwerking van een klantverzoek
- 3xx (omleidingen): Codes van deze klasse vertellen de client dat er nog een verzoek (meestal naar een andere URI) moet worden gedaan om de bewerking te laten slagen.
- 4xx (clientfouten): Codes van deze klasse zijn bedoeld om fouten aan de clientzijde aan te geven
- 5xx (serverfouten): responscodes van deze klasse worden toegewezen voor gevallen van mislukte bewerking als gevolg van een fout van de server
Hieronder staat een tabel met de volgende informatie in de vorm van een spiekbriefje: alle digitale aanduidingen van statuscodes, de naam van de codes - een verklarende zin in het Engels met vertaling in het Russisch, evenals een korte beschrijving van elk serverantwoord .
| Groep | Reactiecode | Codenaam | Beschrijving van de serverreactie |
|---|---|---|---|
| Informatie | 100 | Doorgaan | De server is tevreden met de eerste informatie over het verzoek, de client kan doorgaan met het doorsturen van headers. Verscheen in versie HTTP/1.1. |
| 101 | Schakelprotocol | De server biedt aan om over te schakelen naar een protocol dat geschikter is voor de opgegeven bron; De server moet de lijst met voorgestelde protocollen opgeven in het veld Upgrade-header. Als de klant hierin geïnteresseerd is, stuurt hij een nieuw verzoek met vermelding van een ander protocol. | |
| 102 | Verwerking | Het verzoek is door de server geaccepteerd, maar het duurt lang voordat het is verwerkt. Dit antwoord wordt gebruikt om te voorkomen dat de client de verbinding verbreekt vanwege een time-out. Bij ontvangst van een dergelijk antwoord moet de cliënt de timer opnieuw instellen en zoals gewoonlijk wachten op het volgende commando. Geïntroduceerd in WebDAV. | |
| Succesvol | 200 | OK | Aanvraag succesvol verwerkt. "Succes" hangt af van de HTTP-methode die is aangevraagd:
|
| 201 | Gemaakt | De aanvraag is succesvol afgerond en er is een nieuwe resource aangemaakt. Deze code wordt meestal verzonden als reactie op een PUT "PUT" -verzoek. | |
| 202 | Geaccepteerd | Het verzoek is geaccepteerd, maar nog niet verwerkt. De klant hoeft niet te wachten op de definitieve verzending van het bericht, omdat er een zeer lang proces kan beginnen. | |
| 203 | Niet-gezaghebbende informatie | Deze responscode betekent dat de geretourneerde informatie afkomstig is van een andere bron dan de server. Vergelijkbaar met antwoord 200, maar in dit geval is de verzonden informatie niet afkomstig van de primaire bron en daarom mogelijk niet actueel. | |
| 204 | Geen inhoud | De server heeft het verzoek met succes verwerkt, maar het antwoord bevatte alleen de headers zonder de berichttekst. De opdrachtgever hoeft de inhoud van het document niet bij te werken, maar kan er de ontvangen metadata op toepassen. De client kan ze gebruiken om in de cache opgeslagen headers voor eerdere bronnen bij te werken. | |
| 205 | Inhoud opnieuw instellen | Met deze code dwingt de server de client om de door de gebruiker ingevoerde gegevens opnieuw in te stellen. De server verzendt de hoofdtekst van het bericht niet en het is niet nodig om het document bij te werken. | |
| 206 | Gedeeltelijke inhoud | De server heeft een gedeeltelijk GET-verzoek met succes voltooid en slechts een deel van de inhoud geretourneerd. In de Content-Range-header specificeert de server de bytebereiken van de inhoud. Bij het werken met dergelijke reacties moet speciale aandacht worden besteed aan caching. | |
| Omleidingen | |||
| 300 | Meerkeuze | Deze responscode wordt verzonden wanneer een verzoek meer dan één mogelijk antwoord heeft (op MIME-type, op taal of op basis van andere kenmerken). De server stuurt bij het bericht een lijst met alternatieven mee, waardoor de client of gebruiker automatisch een keuze kan maken. | |
| 301 | Permanent verplaatst | Deze responscode betekent dat de URI van de aangevraagde bron is gewijzigd. De nieuwe URI wordt opgegeven in het veld Locatie van de header. | |
| 302 | Gevonden; Tijdelijk verplaatst | Deze responscode betekent dat de aangevraagde bron tijdelijk beschikbaar is op een andere URI die is opgegeven in het veld Locatie van de header. | |
| 303 | Zie Overige | De server heeft dit antwoord verzonden om de client opdracht te geven de gevraagde bron op een andere URI te verkrijgen met behulp van de GET-methode. Er is een andere URI opgegeven in het veld Locatie van de header. | |
| 304 | Niet gewijzigd | Dit antwoord wordt gebruikt voor cachedoeleinden. Het vertelt de cliënt dat het antwoord niet is gewijzigd. Op deze manier kan de client dezelfde in de cache opgeslagen versie van het antwoord blijven gebruiken. In dit geval mag het serverbericht geen hoofdtekst bevatten. | |
| 305 | Gebruik proxy | Het verzoek aan de aangevraagde bron moet worden gedaan via een proxyserver waarvan de URI is opgegeven in het veld Locatie van de header. Deze responscode wordt voornamelijk om veiligheidsredenen niet ondersteund. | |
| 306 | ongebruikt | Deze responscode wordt niet meer gebruikt en is momenteel gereserveerd. | |
| 307 | Tijdelijke omleiding | De aangevraagde bron is kortstondig beschikbaar op een andere URI die is opgegeven in het veld Locatie van de header. Heeft dezelfde semantiek als de 302 Found HTTP-antwoordcode, behalve dat de client zou niet moeten | |
| 308 | Permanente omleiding | Dit betekent dat de bron zich nu permanent op een andere URI bevindt die is opgegeven in het veld Locatie van de header. Heeft dezelfde semantiek als de HTTP 301 Permanent verplaatst-antwoordcode, behalve dat de client zou niet moeten verander de gebruikte HTTP-methode: als POST werd gebruikt in het eerste verzoek, moet het POST gebruiken in het tweede verzoek. | |
| Fouten van klanten | |||
| 400 | Slecht verzoek | Dit antwoord betekent dat de server het clientverzoek niet kon begrijpen vanwege een syntaxisfout. | |
| 401 | Ongeautoriseerd | Authenticatie is vereist om het gevraagde antwoord te ontvangen. Dit is vergelijkbaar met een 403-antwoord, maar in dit geval is authenticatie mogelijk. De antwoordheader moet het veld WWW-Authenticate bevatten met een lijst met authenticatievoorwaarden. | |
| 402 | Betaling vereist | Deze responscode is gereserveerd voor toekomstig gebruik. Het oorspronkelijke doel van het maken van deze code was om deze te gebruiken voor digitale betalingssystemen, maar wordt momenteel niet gebruikt. | |
| 403 | Verboden | De server heeft het verzoek begrepen, maar weigert eraan te voldoen vanwege beperkingen op de toegang van de client tot de opgegeven bron. De client heeft geen toegangsrechten tot de inhoud, dus de server weigert het juiste antwoord te geven. De meest waarschijnlijke reden voor de beperking is een poging om toegang te krijgen tot systeembronnen van de webserver (bijvoorbeeld .htaccess- of .htpasswd-bestanden) of tot bestanden waarvoor de toegang is geweigerd met behulp van configuratiebestanden. | |
| 404 | Niet gevonden | De server kan de gevraagde bron niet vinden. De belangrijkste reden is een fout in de spelling van het webpagina-adres. Deze responscode is waarschijnlijk de meest bekende vanwege de prevalentie ervan op internet. | |
| 405 | Methode niet toegestaan | De verzoekmethode is bekend bij de server, maar is uitgeschakeld en kan niet worden gebruikt. In het antwoord moet de server de beschikbare methoden in de Allow-header aangeven, gescheiden door een komma. Twee vereiste methoden: GET en HEAD mogen nooit worden uitgeschakeld en mogen deze foutcode niet retourneren. | |
| 406 | Niet acceptabel | De aangevraagde URI kan niet voldoen aan de kenmerken die in de header zijn doorgegeven. Als de methode niet HEAD was, zou de server een lijst met acceptabele kenmerken voor de gegeven bron moeten retourneren. | |
| 407 | Proxyverificatie vereist | Dit antwoord is vergelijkbaar met 401, maar hier vindt de authenticatie plaats tegen de proxyserver. | |
| 408 | Time-out aanvragen | Er is een time-out opgetreden bij het wachten op een transmissie van de client. Dit betekent dat de server deze ongebruikte verbinding wil uitschakelen. Houd er rekening mee dat sommige servers eenvoudigweg de verbinding verbreken zonder dit bericht te verzenden. | |
| 409 | Conflict | Dit antwoord wordt verzonden wanneer het verzoek conflicteert met de huidige status van de server. Dit is bijvoorbeeld mogelijk wanneer twee clients een bron proberen te wijzigen met behulp van de PUT-methode. | |
| 410 | Weg | Dit antwoord wordt verzonden wanneer de gevraagde inhoud op de opgegeven URL van de server is verwijderd. In dit geval kent de server de locatie van het alternatieve document (bijvoorbeeld een kopie) niet. | |
| 411 | Lengte vereist | De server heeft het verzoek afgewezen omdat het headerveld Content-Length niet is gedefinieerd en de server dit vereist. Dit antwoord is normaal voor verzoeken zoals POST en PUT. Als bestanden bijvoorbeeld worden gedownload via de opgegeven URI en de server een limiet heeft voor de grootte ervan. | |
| 412 | Voorwaarde is mislukt | De client heeft voorwaardelijke velden opgegeven in de verzoekheaders (bijvoorbeeld If-Match, enz.), waaraan de server niet voldoet. | |
| 413 | Laadvermogen te groot. Eerder: aanvraagentiteit te groot | Het verzoekobject is groter dan de beperkingen die op de server zijn gedefinieerd. De server kan de verbinding sluiten om verdere verzending van het verzoek te stoppen of een Retry-After-headerveld retourneren waarin de tijd wordt gespecificeerd waarna een soortgelijk verzoek kan worden herhaald. | |
| 414 | URI te lang. Voorheen - Request-URI te lang | De door de client opgevraagde URI is te lang om door de server te worden verwerkt. Deze fout kan bijvoorbeeld worden geactiveerd wanneer de client lange parameters probeert door te geven via de GET-methode in plaats van de POST-methode. | |
| 415 | Niet-ondersteund mediatype | Het formaat van de gevraagde gegevenstypen wordt niet ondersteund door de server, dus de server wijst het verzoek af. Om de een of andere reden weigert de server met deze methode met het opgegeven gegevenstype te werken. | |
| 416 | Bereik niet bevredigend. Eerder - Aangevraagd bereik is niet bevredigend | Er kan niet worden voldaan aan het bereik dat is opgegeven in het veld Bereikkoptekst in de aanvraag; het is mogelijk dat het bereik buiten de gegevensgrootte van de doel-URI valt en dat het veld If-Range ontbreekt. | |
| 417 | Verwachting mislukt | Deze responscode betekent dat de verwachting die is opgegeven in het veld Expect header van het verzoek niet door de server kan worden vervuld. | |
| 421 | Verkeerd gericht verzoek | Het verzoek is doorgestuurd naar een server die geen antwoord kon geven. | |
| 451 | Niet beschikbaar om juridische redenen | De toegang tot de bron is om juridische redenen gesloten (bijvoorbeeld op verzoek van overheidsinstanties of op verzoek van de houder van het auteursrecht in geval van inbreuk op het auteursrecht). Geïntroduceerd in het IETF-concept door Google, waarbij de foutcode een verwijzing is naar de roman Fahrenheit 451 van Ray Bradbury. Het werd op 21 december 2015 aan de standaard toegevoegd. | |
| Serverfouten | |||
| 500 | Interne serverfout | De server wordt geconfronteerd met een situatie waarin hij niet weet wat hij moet doen. Elke interne serverfout die niet valt onder de reikwijdte van andere fouten in de klasse. | |
| 501 | Niet geïmplementeerd | De aanvraagmethode wordt niet ondersteund door de server en kan niet worden verwerkt. Een typisch antwoord voor gevallen waarin de server de in het verzoek gespecificeerde methode niet begrijpt. De enige methoden die de server nodig heeft om deze code te ondersteunen (en daarom deze code niet mogen retourneren) zijn GET en HEAD . | |
| 502 | Slechte gateway | Deze foutreactie betekent dat de server, hoewel hij als gateway fungeert om het antwoord te verkrijgen dat nodig is om het verzoek te verwerken, een onjuist antwoord heeft ontvangen. De server, die als gateway of proxy fungeert, heeft een ongeldig antwoordbericht ontvangen van de upstream-server. | |
| 503 | Dienst niet beschikbaar | De server is niet klaar om het verzoek te verwerken. De server kan vanwege technische redenen (onderhoud, overbelasting, enz.) tijdelijk geen verzoeken verwerken. Houd er rekening mee dat u samen met dit antwoord een gebruiksvriendelijke pagina moet indienen waarin het probleem wordt uitgelegd. Deze antwoorden moeten worden gebruikt voor tijdelijke omstandigheden, en de Retry-After HTTP-header moet, indien mogelijk, de geschatte tijd bevatten totdat de service is hersteld. De webmaster moet ook de caching-gerelateerde headers controleren die samen met dit antwoord worden verzonden, aangezien deze tijdelijke antwoorden doorgaans niet in de cache worden opgeslagen. | |
| 504 | Gateway-time-out (Gateway reageert niet) | Deze foutreactie wordt gegeven wanneer de server als gateway fungeert en niet op tijd een reactie kan ontvangen. De server in de rol van gateway of proxyserver heeft niet gewacht op een reactie van de upstream-server om het huidige verzoek te voltooien. | |
| 505 | HTTP-versie niet ondersteund | De HTTP-protocolversie die in het verzoek wordt gebruikt, wordt niet ondersteund door de server (of de server weigert de opgegeven versie te ondersteunen). | |
| 509 | Bandbreedtelimiet overschreden | Deze code wordt gebruikt wanneer een website de toegewezen limiet voor verkeersverbruik overschrijdt. In dit geval moet de site-eigenaar contact opnemen met zijn hostingprovider. Op dit moment wordt deze code in geen enkele RFC beschreven en wordt deze alleen gebruikt door de module “bw/limited”, die is opgenomen in het cPanel-hostingcontrolepaneel, waar deze werd geïntroduceerd. |
Onmogelijk zonder de reacties van de server te kennen.
Voorbeeld:
404 Niet gevonden
Verdere acties zijn precies afhankelijk van welke responscode de server of pagina heeft gegeven. Omdat de set codes standaard is voor alle sites/pagina's/servers, zullen de acties bij het uitgeven van een bepaalde code ook standaard zijn.
Tegenwoordig zijn er 5 hoofdklassen responscode:
1xx: Informatief (Russisch informatief) - het verzoek is correct ontvangen, maar de verwerking ervan is niet voltooid.
2xx: Success (Russisch: Succesvol) - het verzoek is correct ontvangen en met succes verwerkt.
3xx: Redirection (Russisch: Redirection) - omleidingscodes naar andere pagina's.
4xx: Client Error (Russisch: Client error) - fout aan de clientzijde.
5xx: Serverfout (Russisch: Serverfout) - fout aan de serverzijde.
Laten we nu enkele van de IANA-statuscodes afzonderlijk bekijken.
Serverreactie 1XX
100 Ga verder met servercode
100 Continue meldt dat de communicatie met de server al tot stand is gebracht, dat de server het juiste verzoek heeft geaccepteerd en dat er nu gegevens worden uitgewisseld tussen de server en de client. Deze code is tijdelijk, d.w.z. hij wordt altijd gevolgd door een ander. Code 100 is intern en is geen foutcode. Die. "De deur staat open, lees wat je nodig hebt, als je klaar bent, sluit je hem." Code 100 wordt mogelijk niet gegenereerd als de gebruiker al een deel van de gegevens van de server heeft ontvangen.
101 Schakelprotocollen
Deze code is ook niet foutief. Wordt gegenereerd bij het overschakelen van het ene protocol naar het andere. Bijvoorbeeld bij een verzoek om over te schakelen van een oudere versie van HTTP naar een nieuwere.
Dit is een van de eenvoudigste servercodes. Het betekent dat er een verzoek is ontvangen van de gebruiker om het type protocol te wijzigen dat op de webserver wordt gebruikt, en dat de server hiermee heeft ingestemd.
102 Verwerking
In zekere zin is dit analoog aan code 100. Deze wordt gegenereerd wanneer het verwerken van een verzoek lang kan duren. Voor deze doeleinden wordt de wachttimer gereset en vindt het wachten op verdere commando's zoals gebruikelijk plaats. Het is ook geen foutcode.
Serverantwoord 200 OK
Het neemt terecht de allereerste plaats in qua belang en populariteit, omdat Dit is wat de server geeft als het verzoek van de gebruiker succesvol en correct is verwerkt.
Serverantwoord 301
Het is ook een van de gebruikelijke responscodes. Het rapporteert dat de opgevraagde pagina op een bepaald adres niet langer beschikbaar is en verwijst vervolgens door naar een ander adres. Een 301-omleiding kan bijvoorbeeld worden gebruikt bij het “verplaatsen” van een site van het HTTP-protocol naar HTTPS (meestal wordt dit geïmplementeerd via het .htaccess-bestand, beschikbaar op Apache-servers).
Serverantwoord 302
Deze code geeft aan dat de locatie van de opgevraagde pagina tijdelijk is gewijzigd. Ook moet informatie worden verstrekt over de nieuwe locatie van het opgevraagde document. Deze code werd oorspronkelijk gebruikt als de belangrijkste omleidingsmethode.
Serverantwoord 404
Dat is alles, de enige mensen die de 404-serverreactiefout niet zagen, waren degenen die nog niet geboren waren en degenen die stierven vóór de creatie van internet. Deze code geeft aan dat het opgevraagde document om een of andere reden niet beschikbaar is op de site. De serverresponsfoutcode 404 mag alleen worden geretourneerd als er nooit een document op het door de gebruiker opgegeven adres is geweest. Als een document eerder beschikbaar was op dit adres en vervolgens van de site werd verwijderd, zou de server een code 410 moeten retourneren, en niet 404.
Valse 404 pagina's
De meeste webmasters besteden geen aandacht aan 404-pagina’s, maar dit kan de ranking van de site ernstig schaden. Het is een paradox, maar een pagina met de melding 404 File Not Found geeft niet altijd een 404-code weer. Dergelijke pagina's worden meestal “Soft 404” genoemd. De redenen hiervoor zijn simpel: om de een of andere reden retourneert de pagina een andere code dan 404 en 410, bijvoorbeeld 200. Dit is heel goed mogelijk als de pagina al is gemaakt, maar er nog geen inhoud op staat.
Serverreactie 500
Alle codes uit de 5xx-serie geven aan dat de server de verwerking van het verzoek niet kan voltooien. Samen met de code moet er een verklarende hint (met een reden) in het Engels verschijnen.
500 Interne serverfout
Code 500 wordt gegeven in geval van een interne serverfout, met uitzondering van andere fouten van klasse 5xx. Een dergelijke fout kan optreden wanneer de link onmiddellijk op het moment van het verzoek op de server wordt gegenereerd. Het eenvoudigste voorbeeld is een interne zoekopdracht op een site: er staat fysiek geen document op de gevraagde link.
Serverantwoord 502
Code 502 kan worden weergegeven in gevallen waarin de server de rol van gateway of proxy speelt, maar het niet mogelijk was om “een gemeenschappelijke taal te vinden” tussen de server en de upstream-server, dat wil zeggen dat dit in feite eenvoudigweg een gegevensuitwisselingsfout is .
Serverreactie 550
Als fout 550 optreedt, moet u controleren hoe correct de MX-records zijn geschreven om deze serverreactiefouten te elimineren.
De uitvoer zal een tabel zijn.
U moet ervoor zorgen dat deze de benodigde gegevens bevat om uw e-mail te laten werken:
BELANGRIJK! Het mixen van MX-records is niet toegestaan, d.w.z. de tabel in de uitvoer mag alleen die MX-records bevatten die specifiek nodig zijn voor uw e-mail. Indien nodig moet u de administratie aanpassen door fouten te corrigeren en/of onnodige items te verwijderen.
Hoe u server- (pagina-)responscodes kunt krijgen via Yandex
Stap 1. Controleer de serverreactiecode voor de sitepagina die in de zoekopdracht moet voorkomen.
Open een pagina van uw website die in de Yandex-zoekresultaten staat en kopieer vervolgens de URL uit de adresbalk.
Nu gaan we naar de Yandex-service (http://webmaster.yandex.ru/server-response.xml), waarmee je de site door de ogen van een robot kunt bekijken en de reactiesnelheid van de server kunt controleren in het Yandex-paneel.
Plak eenvoudig de URL van de pagina waarin we geïnteresseerd zijn in het tekstveld en klik op de knop "Controleren". In dit geval hebben we een 200 OK-code ontvangen, wat aangeeft dat de pagina normaal werkt.
Stap 2. Controleer de reactie van de server op een duidelijk niet-bestaande pagina.
Voer in dezelfde service domeinnaam/some_crocozyabr in
In dit geval hebben we een 301 Permanent verplaatst-antwoord ontvangen. Dit geeft aan dat het paginaadres onjuist is en dat de pagina wordt omgeleid naar het juiste adres.
Hoe kan ik anders de responscodes van de server (site) achterhalen?
Als alternatief kunt u de responscode invoeren met behulp van de http://mainspy.ru-service. Het werkt op dezelfde manier als de Yandex-service: voer de gewenste URL in en klik op "Controleren". De responscode staat in dit geval op de allereerste regel:
Bertal laat je, in tegenstelling tot Mainspy, niet alleen naar de pagina kijken door de ogen van een Yandex-bot, maar ook door de ogen van de zoekrobots van Bing en Google, en als bonus kan het populaire browsers emuleren. Laten we voor het gemak dezelfde pagina's bekijken door de ogen van GoogleBot. In dit geval wordt de responscode groen gemarkeerd.
Bulkcontrole van server(site)reacties online
Het massaal controleren van responscodes kan nuttig zijn voor het vinden van kapotte sites waarop links zijn gekocht (via uitwisselingen of rechtstreeks - het maakt niet uit).
Dimax.biz - http://backlinks-checker.dimax.biz/tools/proverka_otveta_servera.php - dit is een van de beste checkers. Het enige negatieve is dat je in de gratis modus niet meer dan 2 verzoeken van elk 50 links kunt doen. Voor “serieuzere” volumes zul je een betaald PRO-tarief moeten gebruiken. Bij de uitvoer krijgen we een lijst gesorteerd op responscode. In dit geval is sorteren niet nodig, omdat Er staan slechts 2 adressen in de lijst, en beide geven code 200.
Urlitor is een andere dienst voor massaverificatie van responscodes. Het goede aan de service is dat de testresultaten in tabelvorm zijn weergegeven, zodat deze gemakkelijker te begrijpen zijn. Overigens zijn de links in de tabel klikbaar.
Hoe controleer ik de snelheid (tijd) van de reactie van de siteserver?
Het is onmogelijk om te tellen hoeveel van dergelijke diensten er al zijn gemaakt. Laten we er een paar bekijken.
Dit is een Engelstalige tool die de snelheid in alle parameters analyseert. Met zijn hulp kunt u binnen enkele seconden de snelheid achterhalen, hoeveel de geteste pagina weegt, en ook een beoordeling en aanbevelingen krijgen om deze te verbeteren. Het voordeel van deze dienst is dat elk afzonderlijk element wordt geanalyseerd. Met deze analyse kunt u achterhalen wat het laden van een bepaalde pagina en/of de site als geheel precies vertraagt.
Die sneller laadt
Het belangrijkste kenmerk van deze service is dat deze de laadtijd van twee bronnen tegelijkertijd analyseert. Hierdoor kun je erachter komen welke van de twee bronnen sneller is. Het enige negatieve is dat de resultaten kunnen verschillen op verschillende verbindingen en in verschillende browsers.
Google PageSpeed Insights
Google PageSpeed Insights is ook een van de krachtigste tools voor het meten van de snelheid van mobiele en desktopversies. De beoordeling vindt plaats op een schaal van 100 punten. 85 punten of meer is een goede indicator. Bovendien geeft het als bonus aanbevelingen voor verbetering.
Lange serverreactie
Een reactie die langer dan een halve seconde duurt, wordt gewoonlijk ‘lang’ genoemd. Daarom kan het zijn dat u bij het langdurig laden van de site een bericht in de browser ziet: “de time-out voor een reactie van de server is overschreden.” Er kunnen veel redenen zijn voor een lang antwoord:
Complexe logica voor het verstrekken van gegevens
Vanwege hun grote aantal heeft de server geen tijd om inkomende verzoeken tijdig te verwerken
De zoekopdrachten zelf (complex of niet-geoptimaliseerd, of beide)
Query's naar een groot aantal externe bronnen
Groot aantal uitvoerbare bestanden
Het duurt lang voordat de webserver zelf het verzoek verwerkt.
De meest pijnlijke gebieden van serverprestaties:
Gebruikte webserver (Apache, IIS).
Een aantal webservers kan vertragingen veroorzaken, zelfs bij het aanbieden van statische bestanden, omdat... Op architectonisch niveau zijn ze niet ontworpen om een groot aantal verzoeken te verwerken en hierdoor kan er een melding verschijnen dat de time-out voor een antwoord van de server is overschreden. Daarom is het voor de normale werking van de webserver zinvol om nginx te gebruiken (en in combinatie met Apache, php-fpm en andere applicatieservers voor het verwerken van berekeningen aan de serverzijde).
OpCache gebruiken.
Verkort de responstijd van de server door uitvoerbare code (sitescripts) in de cache op te slaan. Hiermee kunt u een kant-en-klaar resultaat gebruiken in plaats van elke keer PHP-instructies in binaire code te vertalen. Maar deze caching heeft niets gemeen met het cachen van de resultaten van het uitvoeren van PHP-scripts.
Databasequery's.
De tweede stap naar serverprestaties is het opzetten van tabellen (indexen) in de database en het structureren ervan om de verwerking van zoekopdrachten te vergemakkelijken. Dit omvat ook het herberekenen van tussenresultaten en het opslaan van de meest gebruikte resultaten in afzonderlijke tabellen. Dit zal het verbruik van serverbronnen meerdere malen verminderen en de responstijd van de server helpen verkorten.
Complexe logica voor gegevensverwerking.
De derde stap is het vereenvoudigen van de serverlogica. In wezen elimineert het alleen maar onnodige bewerkingen en profileert het de uitvoeringstijd van scripts op de server.
Toegang tot diensten van derden.
Verzoeken aan services van derden, geschreven in de code van serverscripts, zijn een 'algemeen verhaal' dat voor veel verrassingen kan zorgen, aangezien de prestaties van de services waarvan gegevens worden opgevraagd bijna nooit door iemand worden gecontroleerd. Maar de responstijd van een service van derden heeft rechtstreeks invloed op de responstijd van de server. Daarom is het het beste om alleen interne bronnen te gebruiken in serverquery's, die op elk moment kunnen worden gecontroleerd op prestatiekwaliteit, of om gegevens op te vragen bij de client in een uitgestelde modus.
Waarom de reactiesnelheid van de webserver de promotie beïnvloedt.
Ten eerste omdat de laadsnelheid een van de rankingfactoren is (hoewel niet doorslaggevend). Google stelt openlijk dat minder dan 1% van de websites scoort op paginasnelheid. MAAR…
Ten tweede, als het laden van de pagina te lang duurt, zal de gebruiker deze eenvoudigweg sluiten. Dit gebruikersgedrag wordt gewoonlijk “weigering” genoemd. Overigens hebben ‘weigeringen’ een directe impact op posities in de zoekresultaten. Hoe hoger de downloadsnelheid, hoe lager het uitvalpercentage en, als gevolg daarvan, hoe hoger de posities.
Er is een time-out opgetreden tijdens het wachten op een reactie van de server.
Ten eerste is het belangrijk om de oorzaak van de storing te begrijpen. Die. de gebruiker voert het adres in en de browser verzendt op dit moment een groep verzoeken en start ook een aftellende stopwatch voor elk van hen. Als de browser na een bepaalde tijd geen antwoord op zijn verzoek ontvangt, ziet de gebruiker zo'n onaangenaam beeld.
Er kunnen verschillende hoofdredenen zijn voor het mislukken:
- Het is onmogelijk om verbinding te maken met de site vanwege de onstabiele werking van de servers;
- Kapotte browserinstellingen of rommel;
Problemen met de internetverbinding aan de kant van de gebruiker;
De bron is geblokkeerd.
Wat te doen om op te lossen?
Als de fout enkelvoudig is, laadt u de pagina opnieuw met de combinatie Ctrl+F5. Mogelijk moet u de pagina meerdere keren opnieuw laden. Als dit niet helpt, controleer dan uw internetverbinding.
Netwerkinstellingen.
1. Sommige sites zijn soms grillig. Voor dynamische IP is de oplossing eenvoudig: start de router opnieuw op door de stroom uit te schakelen.
2. Een trage verbinding veroorzaakt soms de ERR_CONNECTION_TIMED_OUT-fout. De internetsnelheid kan worden gecontroleerd met behulp van Yandex Internetometer. Als de snelheid te laag is, dient u contact op te nemen met uw internetprovider.
3. U moet “Netwerkeigenschappen” controleren op de aanwezigheid van externe DNS-adressen. Als er dergelijke adressen zijn, verwijder deze dan (nadat u ze ergens opnieuw hebt geschreven, voor het geval dat) en controleer het systeem op virussen met behulp van antivirussoftware die op de pc is geïnstalleerd - NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web, enz. Voor deze doeleinden kunt u het beste Live downloaders gebruiken.
4. Controleer de instellingen van de router zelf. De MTU-parameter gaat meestal verloren. Het is onmogelijk om universele aanbevelingen te geven voor het opzetten van een router, omdat... dit is rechtstreeks afhankelijk van zowel het routermodel als de internetprovider. Typische MTU-waarden zijn 1500, 1460, 1476.
Wat moet de responstijd van de server zijn?
En meteen de specifieke cijfers:
De hoogste conversiepercentages gelden voor pagina's die in respectievelijk 1,8 en 2,7 seconden volledig worden geladen voor desktop- en mobiele versies.
Het laagste bouncepercentage geldt voor pagina's die in respectievelijk 1 en 0,7 seconden volledig worden geladen voor desktop- en mobiele versies.
Deze cijfers zijn afkomstig uit een onderzoek van Akamai Technologies.
U heeft dus de site gecontroleerd op laadsnelheid. Maar hoe te reageren op de resultaten?
<1 секунды - идеал
1-2 seconden - bijna ideaal
3-5 seconden - draaglijk, maar het is logisch om het af te maken
5-10 seconden - slecht, moet het dringend afmaken
≥10 seconden - erg slecht, je moet het NOODGEVAL afmaken
We mogen echter één uiterst belangrijke regel niet vergeten: de downloadsnelheid moet hoger zijn dan die van concurrenten. Uit onderzoek van The New York Times is gebleken dat een verschil van 0,25 seconde al genoeg kan zijn om bezoekers de voorkeur te geven aan een snellere site. En voordat je met je ogen kunt knipperen (in de meest letterlijke zin), zal de gebruiker je verlaten voor een concurrent.
Het verminderen van de serverreactie
Grafische optimalisatie.
We zeiden eerder dat sommige checkers ook optimalisatie-aanbevelingen geven. Daaronder vindt u de adressen van afbeeldingen die kunnen worden geoptimaliseerd door ze te verkleinen.
Gebruik browsercache.
De browser downloadt de afbeeldingen naar de cache. Hierdoor is het opnieuw downloaden van afbeeldingen vanaf de server niet langer nodig, wat veel tijd bij het downloaden zal besparen.
Compressie inschakelen.
Relevant als gzip wordt gebruikt. Als gevolg hiervan wordt het gegevensvolume 4 of zelfs 5 keer kleiner. Hoe kleiner het volume van de verzonden gegevens, hoe minder tijd het kost om deze over te dragen.
Verkort de responstijd van de server.
Met de dienst Pingdom kunt u berekenen hoe lang het duurt voordat de server een responscode verzendt. De ideale tijd is niet meer dan 0,2 seconden.
Deze instructies zullen de site aanzienlijk versnellen. Er bestaat echter een risico dat de functionaliteit of het uiterlijk wordt aangetast. Daarom is het absoluut noodzakelijk om vóór elke actie back-ups te maken van de bronbestanden. Het kan ook geen kwaad om te overleggen met technische specialisten.
Tijdens het opvragen van informatie bij een externe webserver kan er een fout optreden, waarna de webserver een reactie verzendt HTTP-foutcode. Bijvoorbeeld 404 – Niet gevonden (bron niet gevonden).
HTTP-statuscodes bestaan uit drie cijfers van 100 tot 510. Ze zijn onderverdeeld in de volgende groepen:
- Informatief (100-105)
- Succesvol (200-226)
- Omleiding (300-307)
- Clientfout (400-499)
- Serverfout (500-510)
Voer de code van drie tekens waarin u geïnteresseerd bent in het onderstaande veld in en ontvang de beschrijving ervan:
Zoekopdracht
Beschrijving
Doorgaan De server is tevreden met de eerste informatie over het verzoek, de client kan doorgaan met het verzenden van headers. Geïntroduceerd in HTTP/1.1.
Van protocol wisselen De server biedt aan om over te schakelen naar een protocol dat geschikter is voor de opgegeven bron; De server moet de lijst met voorgestelde protocollen opgeven in het veld Update header. Als de klant hierin geïnteresseerd is, stuurt hij een nieuw verzoek met vermelding van een ander protocol. Geïntroduceerd in HTTP/1.1.
Verwerking De aanvraag is geaccepteerd, maar de verwerking ervan zal lang duren. Wordt door de server gebruikt om te voorkomen dat de client de verbinding verbreekt vanwege een time-out. Bij ontvangst van een dergelijk antwoord moet de cliënt de timer opnieuw instellen en zoals gewoonlijk wachten op het volgende commando. Geïntroduceerd in WebDAV.
OK Succesvolle aanvraag. Als de klant om gegevens heeft gevraagd, vindt u deze in de koptekst en/of de hoofdtekst van het bericht. Geïntroduceerd in HTTP/1.0.
Gemaakt Als gevolg van de succesvolle uitvoering van het verzoek is er een nieuwe resource gemaakt. De server moet zijn locatie aangeven in de locatieheader. Het wordt aanbevolen dat de server [bron niet gespecificeerd 336 dagen] ook de kenmerken van de aangemaakte bron in de header aangeeft (bijvoorbeeld in het veld Content-Type). Als de server er niet zeker van is dat de bron daadwerkelijk zal bestaan op het moment dat de client dit bericht ontvangt, is het beter om een antwoord met code 202 te gebruiken. Geïntroduceerd in HTTP/1.0.
Geaccepteerd Het verzoek is in behandeling genomen, maar niet voltooid. De klant hoeft niet te wachten op de definitieve verzending van het bericht, omdat er een zeer lang proces kan beginnen. Geïntroduceerd in HTTP/1.0.
Niet-geautoriseerde informatie Vergelijkbaar met antwoord 200, maar in dit geval is de verzonden informatie niet afkomstig van de primaire bron (back-up, een andere server, enz.) en is daarom mogelijk niet actueel. Geïntroduceerd in HTTP/1.1.
Geen inhoud De server heeft het verzoek met succes verwerkt, maar het antwoord bevatte alleen de headers zonder de berichttekst. De opdrachtgever hoeft de inhoud van het document niet bij te werken, maar kan er de ontvangen metadata op toepassen. Geïntroduceerd in HTTP/1.0.
Inhoud resetten De server dwingt de client om de door de gebruiker ingevoerde gegevens opnieuw in te stellen. De server verzendt de hoofdtekst van het bericht niet en het is niet nodig om het document bij te werken. Geïntroduceerd in HTTP/1.1.
Gedeeltelijke inhoud De server heeft een gedeeltelijk GET-verzoek met succes voltooid, waarbij slechts een deel van het bericht is geretourneerd. In de Content-Range-header specificeert de server de bytebereiken van de inhoud. Bij het werken met dergelijke reacties moet speciale aandacht worden besteed aan caching. Geïntroduceerd in HTTP/1.1. (meer details...)
Multi-Status De server verzendt de resultaten van verschillende onafhankelijke bewerkingen tegelijk. Ze worden in de berichttekst zelf geplaatst als een XML-document met een multistatusobject. Het wordt afgeraden om statussen uit de 1xx-serie in dit object te plaatsen vanwege zinloosheid en redundantie. Geïntroduceerd in WebDAV.
IM gebruikt De A-IM-header van de client is met succes ontvangen en de server retourneert de inhoud, rekening houdend met de opgegeven parameters. Geïntroduceerd in RFC 3229 om het HTTP-protocol uit te breiden met ondersteuning voor delta-codering.
Meerdere keuzes Gegeven een URI zijn er meerdere opties om de bron te presenteren op basis van MIME-type, taal of andere kenmerken. De server stuurt bij het bericht een lijst met alternatieven mee, waardoor de client of gebruiker automatisch een keuze kan maken. Geïntroduceerd in HTTP/1.0.
Permanent verplaatst Het opgevraagde document is permanent verplaatst naar de nieuwe URI die is opgegeven in het veld Locatie van de kop. Sommige clients gedragen zich verkeerd bij het verwerken van deze code. Geïntroduceerd in HTTP/1.0.
Gevonden, tijdelijk verplaatst Het opgevraagde document is tijdelijk beschikbaar op een andere URI die is opgegeven in de koptekst van het veld Locatie. Deze code kan bijvoorbeeld worden gebruikt bij servergestuurde contentonderhandeling. Sommige clients gedragen zich verkeerd bij het verwerken van deze code. Geïntroduceerd in HTTP/1.0.
Zie Overige Het document met de gevraagde URI moet worden opgevraagd naar het adres in het veld Locatie van de header met behulp van de GET-methode, ook al is het eerste opgevraagd met een andere methode. Deze code werd samen met de 307 geïntroduceerd om dubbelzinnigheid te voorkomen, zodat de server er zeker van kon zijn dat de volgende bron zou worden opgevraagd met behulp van de GET-methode. Een webpagina heeft bijvoorbeeld een tekstinvoerveld voor snelle navigatie en zoeken. Na het invoeren van de gegevens doet de browser een verzoek via de POST-methode, inclusief de ingevoerde tekst in de berichttekst. Als een document met de ingevoerde naam wordt gedetecteerd, reageert de server met code 303, waarbij het permanente adres wordt aangegeven in de locatieheader. Dan zal de browser er gegarandeerd om vragen via de GET-methode om de inhoud te verkrijgen. Anders stuurt de server de zoekresultatenpagina eenvoudigweg terug naar de client. Geïntroduceerd in HTTP/1.1.
Not Modified De server retourneert deze code als de client een document heeft opgevraagd met behulp van de GET-methode, de header If-Modified-Since of If-None-Match heeft gebruikt en het document sinds het opgegeven moment niet is gewijzigd. In dit geval mag het serverbericht geen hoofdtekst bevatten. Geïntroduceerd in HTTP/1.0.
Proxy gebruiken Een verzoek aan de aangevraagde bron moet worden gedaan via een proxyserver waarvan de URI is opgegeven in het veld Locatie van de header. Deze responscode kan alleen worden gebruikt door oorspronkelijke HTTP-servers (geen proxy's). Geïntroduceerd in HTTP/1.1.
(gereserveerd) De eerder gebruikte responscode is momenteel gereserveerd. Vermeld in RFC 2616 (HTTP/1.1-update).
Tijdelijke omleiding De aangevraagde bron is tijdelijk beschikbaar op een andere URI die is opgegeven in het veld Locatie van de header. Deze code werd samen met 303 geïntroduceerd in plaats van 302 om dubbelzinnigheid te voorkomen. Geïntroduceerd in RFC 2616 (HTTP/1.1-update).
Slecht verzoek De server heeft een syntaxisfout gedetecteerd in het verzoek van de client. Geïntroduceerd in HTTP/1.0.
Ongeautoriseerde authenticatie is vereist om toegang te krijgen tot de gevraagde bron. De antwoordheader moet het veld WWW-Authenticate bevatten met een lijst met authenticatievoorwaarden. De klant kan het verzoek herhalen door het veld Autorisatie in de berichtkop op te nemen met de gegevens die nodig zijn voor authenticatie.
Betaling vereist Bestemd voor toekomstig gebruik. Momenteel niet in gebruik. Deze code is bedoeld voor betaalde gebruikersdiensten en niet voor hostingbedrijven. Dit betekent dat deze fout niet door de hostingprovider wordt gegenereerd in geval van niet tijdige betaling voor zijn diensten. Gereserveerd sinds HTTP/1.1.
Verboden De server heeft het verzoek begrepen, maar weigert hieraan te voldoen vanwege beperkingen op de toegang van de client tot de opgegeven bron. Als HTTP-authenticatie vereist is om toegang te krijgen tot een bron, retourneert de server een 401- of 407-antwoord wanneer een proxy wordt gebruikt. Anders worden de beperkingen ingesteld door de serverbeheerder of webapplicatie-ontwikkelaar en kunnen ze van alles zijn, afhankelijk van de mogelijkheden van de gebruikte software. In ieder geval moet de cliënt op de hoogte worden gesteld van de redenen voor de weigering om het verzoek in behandeling te nemen. De meest waarschijnlijke redenen voor de beperking kunnen een poging zijn om toegang te krijgen tot systeembronnen van de webserver (bijvoorbeeld .htaccess- of .htpasswd-bestanden) of bestanden waartoe de toegang is geweigerd met behulp van configuratiebestanden, een vereiste voor niet-HTTP-authenticatie. bijvoorbeeld om toegang te krijgen tot het systeeminhoudsbeheer of de sectie voor geregistreerde gebruikers, of de server is bijvoorbeeld niet tevreden met het IP-adres van de client bij het blokkeren. Geïntroduceerd in HTTP/1.0.
Niet gevonden De meest voorkomende fout bij het gebruik van internet. De belangrijkste reden is een fout bij het spellen van het adres van de webpagina. De server heeft het verzoek begrepen, maar heeft geen overeenkomstige bron gevonden op de opgegeven URI. Als de server weet dat er een document op dit adres stond, is het raadzaam om de code 410 te gebruiken. Het antwoord 404 kan worden gebruikt in plaats van 403 als het nodig is om bepaalde bronnen zorgvuldig te verbergen voor nieuwsgierige blikken. Geïntroduceerd in HTTP/1.0.
Methode niet toegestaan De door de client opgegeven methode kan niet worden toegepast op de huidige bron. In het antwoord moet de server de beschikbare methoden in de Allow-header aangeven, gescheiden door een komma. De server moet deze fout retourneren als de methode bij hem bekend is, maar deze niet specifiek van toepassing is op de bron die in het verzoek is opgegeven. Als de opgegeven methode niet van toepassing is op de gehele server, moet de client code 501 (Not Implemented.) retourneren ). Geïntroduceerd in HTTP/1.1.
Niet acceptabel De aangevraagde URI kan niet voldoen aan de kenmerken die in de header zijn doorgegeven. Als de methode niet HEAD was, moet de server een lijst met acceptabele kenmerken voor deze bron retourneren. Geïntroduceerd in HTTP/1.1.
Proxyverificatie vereist Het antwoord is hetzelfde als 401, behalve dat de verificatie plaatsvindt tegen een proxyserver. Het mechanisme is vergelijkbaar met identificatie op de oorspronkelijke server. Geïntroduceerd in HTTP/1.1.
Request Timeout Er is een time-out van de server opgetreden tijdens het wachten op een transmissie van de client. De klant kan een gelijkaardig eerder verzoek op elk moment herhalen. Deze situatie kan zich bijvoorbeeld voordoen bij het uploaden van een groot bestand naar de server met behulp van de POST- of PUT-methode. Op een bepaald moment tijdens de overdracht reageerde de gegevensbron niet meer, bijvoorbeeld vanwege schade aan de cd of verlies van communicatie met een andere computer op het lokale netwerk. Terwijl de client niets verzendt, wachtend op een reactie van hem, blijft de verbinding met de server behouden. Na enige tijd kan de server de verbinding aan zijn kant verbreken zodat andere clients een verzoek kunnen indienen. Dit antwoord wordt niet geretourneerd wanneer de client de verzending op bevel van de gebruiker met geweld stopt of de verbinding om een andere reden wordt onderbroken, aangezien het antwoord niet langer kan worden verzonden. Geïntroduceerd in HTTP/1.1.
Conflict Het verzoek kon niet worden voltooid vanwege een conflicterende toegang tot de bron. Dit is bijvoorbeeld mogelijk wanneer twee clients een bron proberen te wijzigen met behulp van de PUT-methode, geïntroduceerd in HTTP/1.1.
Verdwenen De server verzendt dit antwoord als de bron zich voorheen op de opgegeven URL bevond, maar is verwijderd en nu niet beschikbaar is. In dit geval kent de server de locatie van het alternatieve document (bijvoorbeeld een kopie) niet. Als de server het vermoeden heeft dat het document in de nabije toekomst kan worden hersteld, is het beter om de code 404 naar de client te sturen, geïntroduceerd in HTTP/1.1.
Lengte vereist Voor de opgegeven bron moet de client Content-Length opgeven in de verzoekheader. Zonder dit veld op te geven, mag u het verzoek niet opnieuw naar de server sturen met behulp van deze URI. Dit antwoord is normaal voor POST- en PUT-verzoeken. Als bestanden bijvoorbeeld worden gedownload via de opgegeven URI en de server een limiet heeft voor de grootte ervan. Dan zou het redelijker zijn om de Content-Length header helemaal aan het begin te controleren en de download onmiddellijk te weigeren, in plaats van een zinloze belasting uit te lokken door de verbinding te verbreken wanneer de client daadwerkelijk een te groot bericht verzendt. Geïntroduceerd in HTTP/1.1.
Voorwaarde mislukt Geretourneerd als aan geen van de voorwaardeheader[onbekende term]-velden van het verzoek is voldaan. Geïntroduceerd in HTTP/1.1.
Request Enty Too Large Wordt geretourneerd als de server weigert het verzoek te verwerken omdat de hoofdtekst van het verzoek te groot is. De server kan de verbinding sluiten om verdere verzending van het verzoek te stoppen. Als het probleem tijdelijk is, wordt aanbevolen om een Retry-After-header in het serverantwoord op te nemen, die aangeeft na hoeveel tijd een soortgelijk verzoek kan worden herhaald. Geïntroduceerd in HTTP/1.1.
Request-URL Too Long De server kan het verzoek niet verwerken omdat de opgegeven URL te lang is. Deze fout kan bijvoorbeeld worden geactiveerd wanneer de client lange parameters probeert door te geven via de GET-methode in plaats van de POST-methode. Geïntroduceerd in HTTP/1.1.
Niet-ondersteund mediatype Om de een of andere reden weigert de server deze methode te gebruiken met het opgegeven gegevenstype. Geïntroduceerd in HTTP/1.1.
Gewenst bereik niet tevreden Het veld Bereik in de verzoekheader specificeerde een bereik buiten de resource en miste het veld If-Range. Als de client een bytebereik heeft overschreden, kan de server de werkelijke grootte retourneren in het veld Content-Range van de header. Dit antwoord mag niet worden gebruikt voor overdrachten van meerdere delen/bytebereiken [bron niet gespecificeerd 336 dagen]. Geïntroduceerd in RFC 2616 (HTTP/1.1-update).
Verwachting mislukt Om de een of andere reden kan de server niet voldoen aan de waarde van het veld Verwacht in de verzoekheader. Geïntroduceerd in RFC 2616 (HTTP/1.1-update).
Onverwerkbare entiteit De server heeft het verzoek met succes geaccepteerd, kan werken met het opgegeven type gegevens, het XML-document in de hoofdtekst van het verzoek heeft de juiste syntaxis, maar er is een soort logische fout waardoor het onmogelijk is om een bewerking uit te voeren op de hulpbron. Ingevoerd in WebDAV.
Vergrendeld De doelbron van het verzoek kan niet worden toegepast op de opgegeven methode. Ingevoerd in WebDAV.
Mislukte afhankelijkheid De uitvoering van het huidige verzoek kan afhankelijk zijn van het succes van een andere bewerking. Als het niet is voltooid en hierdoor kan het huidige verzoek niet worden voltooid, dan zal de server deze code retourneren. Ingevoerd in WebDAV.
Ongeordende verzameling - Verzonden als de client een verzoek heeft verzonden om een positie in een ongesorteerde verzameling aan te geven of om een andere volgorde van elementen van de server te gebruiken [specificeer]. Geïntroduceerd in concept door WebDAV Advanced Collections Protocol.
Upgrade vereist De server geeft aan de client aan dat het protocol moet worden geüpgraded. De antwoordheader moet correct opgemaakte velden Upgrade en Verbinding bevatten. Geïntroduceerd in RFC 2817 om de overgang naar TLS via HTTP mogelijk te maken.
Opnieuw proberen met Wordt geretourneerd door de server als er onvoldoende informatie is ontvangen van de client om het verzoek te verwerken. In dit geval wordt het veld Ms-Echo-Request in de antwoordheader geplaatst. Geïntroduceerd door Microsoft voor WebDAV. Momenteel tenminste gebruikt door het Microsoft Money-programma.
Onherstelbare fout Teruggezonden door de server als het verwerken van een verzoek onherstelbare fouten in de databasetabellen veroorzaakt [bron niet gespecificeerd 336 dagen]. Geïntroduceerd door Microsoft voor WebDAV.
