5xx-serverfouten

Statuscodes in de 500-reeks betekenen dat het probleem bij de server ligt, niet bij de URL. De bekendste: 500 (interne fout, vaak een PHP-exception), 502 (bad gateway, bijvoorbeeld PHP-FPM reageert niet achter nginx), 503 (tijdelijk niet beschikbaar) en 504 (gateway timeout, het antwoord duurde te lang).

Voor Google is een 5xx een signaal om rustiger aan te doen. Googlebot verlaagt de crawlsnelheid als de server fouten geeft of traag wordt. Een 429 (te veel verzoeken) behandelt Google op dezelfde manier. Blijft een URL langere tijd een 5xx geven, dan haalt Google hem uit de index.

Bijzonder geval: robots.txt. Geeft dat bestand een 5xx, dan stopt Google tijdelijk met crawlen van de hele site. Een kapotte robots.txt-route is dus erger dan een kapotte productpagina.

5xx-fouten komen bij webshops vaak in pieken. Tijdens een deploy, een herindexering, een import van duizenden producten of een drukke actiedag. De bezoeker ziet een foutpagina, maar Googlebot ziet het ook en past zijn crawlgedrag aan.

Kortstondige fouten zijn meestal geen probleem. Google komt terug en de URL blijft staan. Het risico zit in structurele fouten: een filtercombinatie die altijd een timeout geeft, een oude productroute die een exception gooit, of een server die elke nacht onder de cronjobs bezwijkt. Die kosten crawlbudget en uiteindelijk indexering.

Je ziet het terug op twee plekken in Search Console. Het rapport Pagina-indexering toont "Serverfout (5xx)". De Crawlstatistieken tonen onder hoststatus of Google problemen had met je server. Je eigen serverlogs geven het volledige beeld, inclusief welke bot welke fout kreeg.

Let ook op traagheid zonder foutmelding. Een server die steeds langer nodig heeft om te antwoorden, leidt tot dezelfde reactie van Google: minder crawls per dag. De Crawlstatistieken tonen de gemiddelde reactietijd. Loopt die op, dan is dat een vroeg signaal dat er iets mis gaat.

Gebruik voor gepland onderhoud een 503 met een Retry-After-header. Magento doet dat met bin/magento maintenance:enable: de shop geeft dan een 503. Laravel heeft php artisan down, ook met een 503 en een optionele --retry. Een gewone 200-pagina met de tekst "we zijn zo terug" is slechter: die kan als lege pagina in de index komen.

Bij Magento zitten structurele 5xx-fouten vaak in PHP-geheugenlimieten, uitgeputte PHP-FPM-workers of trage queries op grote categorieën met veel filters. var/log/exception.log en de nginx-errorlog wijzen meestal direct naar de oorzaak.

Shopify beheert de servers zelf. 5xx-fouten zie je daar zelden en kun je ook niet oplossen. Wel kunnen apps of een headless frontend zelf fouten geven; die vallen dan buiten Shopify.

Een foutpagina die een 200 teruggeeft in plaats van een 5xx, waardoor Google duizenden identieke foutpagina's indexeert. Onderhoudsmodus die dagen aan blijft staan. En monitoring die alleen de homepage controleert, terwijl de fouten op diepere categorieën zitten.

Zet uptime- en foutmonitoring op een steekproef van paginatypes, niet alleen op /. En kijk na elke grote import of release een week lang naar de hoststatus in Search Console.

Kijk bij terugkerende fouten naar het tijdstip. Vallen ze samen met cronjobs, indexers of imports, dan verschuif je die naar rustige uren of geef je ze een eigen worker. Vallen ze samen met piekverkeer, dan is het een capaciteitsvraag voor je hosting.