Een groothandel in Hengelo merkte dat de website af en toe “even” onbereikbaar was. Een klant meldde het, de eigenaar keek, en de site deed het weer. Een week later hetzelfde, in de ochtend. Toen op een vrijdagmiddag een half uur lang. Elke keer dezelfde melding: “503 Service Unavailable”. En elke keer was het over voordat iemand er iets aan kon doen.
Dat is precies het lastige aan een error 503 in WordPress. Anders dan een 500 of een critical error, die blijven tot iemand ingrijpt, is de 503 vaak van voorbijgaande aard. Daardoor wordt hij genegeerd, terwijl hij een vroege waarschuwing kan zijn. In dit artikel leggen we uit wat de code betekent, wat de oorzaken zijn en hoe u erachter komt of het bij u tijdelijk is of structureel.
Wat 503 betekent
Statuscode 503 betekent letterlijk: de dienst is tijdelijk niet beschikbaar. De server bestaat, hij reageert, maar hij kan het verzoek op dit moment niet afhandelen. Het woord “tijdelijk” zit in de definitie. Dat verklaart waarom de fout zo vaak vanzelf overgaat, en waarom zoekmachines er geduldiger mee omgaan dan met een 500: Google interpreteert een 503 als “kom later terug”.
Die goedmoedigheid heeft een grens. Een site die regelmatig 503-fouten geeft, verliest bezoekers en op termijn ook posities in Google, zeker als het uren achter elkaar gebeurt.
Vijf oorzaken van een error 503 in WordPress
Oorzaak 1: de onderhoudsmodus is blijven hangen
Tijdens elke update zet WordPress zichzelf kort in onderhoudsmodus door een bestand .maintenance in de hoofdmap te plaatsen. Bezoekers krijgen dan een 503 met de tekst “Briefly unavailable for scheduled maintenance”. Normaal duurt dat seconden. Wordt de update onderbroken, dan blijft het bestand staan en blijft de site op 503 hangen. De oplossing is het bestand verwijderen; het volledige stappenplan staat in dit artikel over een site die vastzit in onderhoudsmodus.
Dit is de enige oorzaak die niet vanzelf overgaat, en tegelijk de makkelijkste om te herkennen aan de melding.
Oorzaak 2: de limieten van gedeelde hosting
Op een gedeeld hostingpakket deelt u de server met tientallen tot honderden andere sites. Om te voorkomen dat één site alles opslokt, stelt de hostingpartij per klant limieten in voor processorgebruik, geheugen en het aantal gelijktijdige verzoeken. Zodra uw site daar overheen gaat, krijgen nieuwe bezoekers een 503, soms met de tekst “Resource Limit Is Reached”.
Dit is bij kleine en middelgrote sites verreweg de meest voorkomende oorzaak van terugkerende 503-fouten. En het gebeurt op voorspelbare momenten: als een back-up draait, als een zoekmachine of bot de hele site doorloopt, als een nieuwsbrief uitgaat en honderd mensen tegelijk klikken. De groothandel uit de inleiding kreeg de storingen elke keer rond het moment dat hun voorraadkoppeling de producten bijwerkte.
Oorzaak 3: een plugin of proces dat te veel vraagt
Ook zonder harde limieten kan één zware taak de server tijdelijk vollopen. Een back-upplugin die alle bestanden inpakt, een importscript, een beveiligingsscan die alle bestanden leest, een aantal WP-Cron-taken die samen op hetzelfde moment afgaan. Tijdens die piek reageert de site met 503 of gewoon heel traag. De aanwijzing is het patroon: altijd op hetzelfde tijdstip, of altijd na dezelfde handeling.
Oorzaak 4: een piek in bezoekers of bots
Een vermelding in een nieuwsbrief, een regionale krant, een viraal berichtje: opeens tien keer zoveel bezoekers als normaal. Een site zonder goede caching en op een klein pakket loopt dan vol. Vaker nog is het geen menselijk bezoek maar geautomatiseerd verkeer: scrapers, agressieve crawlers of een aanval die de site bewust overbelast. Hoe u dat laatste herkent en welke voorbereidingen zin hebben, leest u in dit artikel over DDoS-aanvallen.
Oorzaak 5: de hosting zelf
Tot slot kan de oorzaak volledig buiten uw site liggen: een server die overbelast is door een andere klant, gepland onderhoud, een storing. Kenmerk: de statuspagina van de hosting meldt iets, of andere sites op dezelfde server zijn ook onbereikbaar. Hier helpt alleen wachten of, bij herhaling, verhuizen.
Tijdelijk of structureel: zo maakt u het onderscheid
- Noteer elke keer het tijdstip en de duur. Zonder dat blijft het gissen. Een gratis uptime-monitor doet dit automatisch en stuurt u een bericht.
- Zoek een patroon. Zelfde tijdstip elke dag? Waarschijnlijk een geplande taak. Na de nieuwsbrief? Bezoekerspiek. Willekeurig? Eerder de hosting of bots.
- Kijk in het hostingpaneel naar het gebruik. De meeste panelen tonen grafieken van processor- en geheugengebruik. Pieken die de limiet raken op de momenten van de storing bevestigen oorzaak 2.
- Kijk in de bezoekerslogs op die momenten. Honderden verzoeken per minuut van één adres of één bot zijn de vingerafdruk van oorzaak 4.
- Vraag de hosting of er op die momenten iets aan de hand was.
Komt de 503 één keer per kwartaal voor en verdwijnt hij binnen een minuut, dan is het tijdelijk en hoeft u weinig te doen. Komt hij wekelijks terug of duurt hij langer dan een paar minuten, dan is het structureel en verdwijnt hij niet vanzelf.
Wat u eraan doet
- Caching inschakelen. Een goede paginacache laat de server tientallen keren zoveel bezoekers aan zonder extra werk. Dit is de goedkoopste maatregel bij pieken.
- Zware taken verplaatsen. Back-ups en scans ‘s nachts laten draaien, niet om negen uur ‘s ochtends.
- Bots beperken. Agressieve crawlers blokkeren via een firewall of een dienst als Cloudflare.
- Hostingpakket herzien. Als de limieten bij normaal gebruik al worden geraakt, is het pakket te klein geworden. Een stap omhoog kost meestal enkele tientjes per maand en lost het structureel op.
Bij de groothandel bleek de voorraadkoppeling elk uur alle 3.000 producten opnieuw weg te schrijven, ook als er niets veranderd was. Na een aanpassing zodat alleen gewijzigde producten werden bijgewerkt, en een stap omhoog in het hostingpakket, is de 503 niet meer teruggekomen.
Wie het patroon niet zelf boven water krijgt, of het liever niet wil, kan de analyse laten uitvoeren. Terugkerende 503-fouten zijn een typisch geval voor foutopsporing door een WordPress-specialist: het werk zit niet in de oplossing maar in het vinden van de oorzaak, en dat vraagt om logs, tijdstippen en ervaring. WebMaintor pakt dit tegen een vast starttarief op; welk bureau u ook kiest, lever de tijdstippen van de storingen aan, want daar begint alles mee.
