hulpbijwordpress

Kies hieronder de foutmelding die letterlijk op je WordPress-site staat en volg alleen die herstelroute. Maak vóór iedere ingreep een back-up van database én bestanden, verander één laag tegelijk en zet een wijziging terug als dezelfde test geen verbetering geeft.

De kritieke fout- en wit-scherm-decoder bovenaan vraagt alleen welk herkenbaar scherm of welke letterlijke melding je ziet. Je voert geen URL, logregel of geheim in; bij twijfel kiest de tool bewust geen specifieke technische oorzaak.

Kies de melding die je ziet

Een foutmelding is nuttiger dan een algemene zoekterm als “WordPress werkt niet”. Noteer daarom de volledige tekst, de getroffen URL, de handeling die eraan voorafging en het exacte tijdstip. Daarmee kun je in een server- of PHP-log dezelfde gebeurtenis terugvinden.

Test ook kort de startpagina, één inhoudspagina, /wp-login.php, /wp-admin/ en een bestaand statisch bestand. Als maar één pagina faalt, kijk je eerder naar routegebonden code of inhoud. Als ook een afbeelding niet laadt, kan de storing vóór WordPress bij hosting, proxy of webserver zitten.

Gebruik de direct-actie boven deze route om snel naar een passende decoder te gaan. De tekst van de melding en het technische bewijs blijven leidend: geen tool kan zonder jouw hostinglogs garanderen welke component de oorzaak is.

Kritieke fouten, witte pagina's en serverfouten

Gebruik deze routes wanneer WordPress niet meer rendert of alleen een algemene fout toont:

• “Er heeft zich een kritieke fout voorgedaan op deze website.” Open de handleiding voor een kritieke WordPress-fout. Controleer eerst de herstelmail en de daarin genoemde plugin, het thema of bestand.
• De wachtwoord-resetmail komt niet aan. Controleer eerst inbox, spam en het juiste beheeradres. Volg daarna de afzonderlijke route voor een WordPress-wachtwoord-resetmail die niet wordt ontvangen, zonder een wachtwoord of resetlink te delen.
• Een volledig wit of leeg scherm zonder tekst. Volg de veilige diagnose voor een wit scherm in WordPress. Schrijf fouten naar een beschermd log en toon technische details niet aan bezoekers.
• HTTP 500 of Internal Server Error. Gebruik de WordPress 500-decoder. Een 500-status kan uit PHP, .htaccess, de webserver of een andere laag vóór WordPress komen.
• Error establishing a database connection. Controleer via de databaseverbindingsroute eerst serverbeschikbaarheid en daarna de vier ingestelde databasewaarden. Deel databasewachtwoorden nooit in screenshots, tickets of logs.

Deze meldingen kunnen op elkaar lijken, maar vragen niet dezelfde ingreep. Een leeg scherm bewijst bijvoorbeeld geen geheugentekort, en een 500-status bewijst niet dat een plugin faalt. De officiële WordPress-pagina over veelvoorkomende fouten noemt meerdere mogelijke oorzaken en gebruikt debugging als startpunt voor verder bewijs.

Toegang, URL's en doorverwijzingen

De site kan technisch draaien terwijl bezoekers of beheerders de bedoelde route niet bereiken:

• 403 Forbidden. De server begrijpt het verzoek maar weigert toegang. Controleer via de WordPress 403-handleiding gericht rechten, eigenaarschap, beveiligingsregels en blokkades. Zet bestanden nooit breed op 777.
• 404 na het wijzigen of opslaan van permalinks. Gebruik de decoder voor WordPress 404 na permalinks. Controleer of alleen nette URL's falen en behandel Apache-, LiteSpeed- en Nginx-regels als verschillende serverlagen.
• Too Many Redirects of ERR_TOO_MANY_REDIRECTS. Volg de WordPress-redirectlus. Leg de Location-keten vast en controleer WordPress-URL's, HTTPS, reverse proxy, CDN, plugins en cache één voor één.

Verander home en siteurl niet blind in de database om een toegangsprobleem op te lossen. Bepaal eerst het bedoelde protocol, domein en installatiepad en controleer of WP_HOME of WP_SITEURL al in wp-config.php staat. Bij een reverse proxy moet ook duidelijk zijn welke gecontroleerde laag HTTPS beëindigt en welke protocolheader WordPress mag vertrouwen.

Geheugen, uitvoeringstijd en updates

Gebruik de exacte PHP-regel of updatefase om deze drie problemen te scheiden:

• Allowed memory size exhausted. De WordPress memory limit-handleiding legt het verschil uit tussen PHP memory_limit, WP_MEMORY_LIMIT en WP_MAX_MEMORY_LIMIT. Meet de effectieve waarde en zoek de verbruiker voordat je tijdelijk en begrensd verhoogt.
• Maximum execution time exceeded. Volg de WordPress max execution time-route. Verdeel grote imports, exports of achtergrondtaken en onderzoek waarom de taak te lang duurt. Een onbeperkte uitvoeringstijd is geen veilige reparatie.
• Briefly unavailable for scheduled maintenance blijft staan. Gebruik de stappen voor WordPress dat in onderhoudsmodus blijft hangen. Controleer eerst of een update nog actief is, maak een herstelset en hernoem .maintenance daarna alleen tijdelijk en omkeerbaar.

Limieten beschermen een gedeelde server tegen een proces dat te veel geheugen of tijd gebruikt. Een hogere waarde kan tijdelijk ruimte geven, maar ook een onbegrensde query, lus of te grote import verbergen. Verhoog daarom nooit zonder foutregel, meetbare test en terugkeerwaarde.

Veilige universele beslisroute

1. Leg de fout en omvang vast

Noteer melding, statuscode, URL, tijdstip, gebruikersactie en recente wijziging. Controleer of de voorkant, het beheer en een statisch bestand hetzelfde reageren. Maak een schermafbeelding pas nadat cookies, tokens, persoonsgegevens, serverpaden en andere geheimen onleesbaar zijn gemaakt.

2. Maak een herstelset

Exporteer de database en download de WordPress-bestanden, inclusief wp-config.php, .htaccess en wp-content. De officiële WordPress-back-uphandleiding legt uit dat bestanden en database aparte onderdelen zijn. Noteer welk herstelpunt bij welke bestanden hoort en controleer hoe je het terugzet.

Kun je geen actuele export maken, controleer dan eerst de beschikbare hostingsnapshot. Zet bij een site met bestellingen, reserveringen of inzendingen nooit zomaar een oude database terug, want daarmee kun je nieuwe gegevens overschrijven.

3. Gebruik herstelmodus en logs

Controleer de inbox en spammap van het beheeradres. De officiële WordPress-herstelmodus kan bij bepaalde fatale PHP-fouten een tijdelijke beheersessie openen waarin het foute onderdeel is gepauzeerd.

Lees daarnaast de PHP-, webserver- en databaselog rond het exacte tijdstip. Als je tijdelijk WordPress-logging gebruikt, volg dan de officiële debughandleiding: log naar een beschermd bestand, houd WP_DEBUG_DISPLAY op false op productie en ruim het log daarna op.

4. Draai één recente wijziging terug

Begon de fout na een pluginupdate, themawijziging, PHP-wissel of deploy, herstel dan alleen die ene laag vanuit een betrouwbare kopie. Test exact dezelfde URL of handeling. Verandert niets, zet dan de uitgangssituatie terug voordat je een volgende hypothese test.

Download vervangende code alleen van de officiële leverancier. Pas geen WordPress-corebestanden aan en verwijder een plugin of thema niet als hernoemen, deactiveren of rollback voldoende is.

5. Isoleer alleen wat het bewijs aanwijst

Noemt het log één plugin, hernoem of deactiveer eerst alleen die plugin. Wijst het naar het thema, test dan in staging of herstelmodus met een geïnstalleerd standaardthema. Wijst het naar geheugen, tijd of database, gebruik dan de specifieke decoder in plaats van willekeurige instellingen te verhogen of tabellen te repareren.

De officiële WordPress-probleemoplossing beschrijft het tijdelijk uitschakelen van plugins zonder wp-admin. Houd er rekening mee dat gewone pluginisolatie must-use plugins en sommige drop-ins niet uitschakelt.

6. Test de volledige gebruikersroute

Een startpagina met status 200 is niet genoeg. Test ook inloggen, beheer, de oorspronkelijke foutactie, formulieren, geplande taken en een onafhankelijke browsersessie. Controleer daarna opnieuw de logs.

Heractiveer caches, beveiligingslagen en tijdelijk uitgeschakelde onderdelen één voor één. Zo zie je direct als een fout terugkeert en blijft de laatste werkende toestand bekend.

7. Ruim op en documenteer

Zet tijdelijke debuginstellingen terug, houd foutweergave uit, verwijder publieke testbestanden en bescherm of archiveer logs. Leg vast welke oorzaak is bevestigd, welke wijziging hielp, welke versie nu draait en hoe je teruggaat.

Plan daarna pas de structurele oplossing, zoals een pluginupdate, begrensde import, correcte proxyconfiguratie of herstel van serverrechten. Geen algemeen stappenplan kan garanderen dat iedere hosting- of maatwerkfout zonder specialistische toegang oplosbaar is.

Is de site daarna technisch stabiel, publiek crawlbaar en schoon van tijdelijke foutpagina's, gebruik dan de praktische AI-workflow voor SEO om contentwerk met bronnen en menselijke controle uit te voeren.

Veelgemaakte fouten

• Zoeken op alleen “WordPress werkt niet”. De exacte melding, status, URL en tijd maken de diagnose gericht.
• Geen database- én bestandenback-up maken. Voor een volledige normale WordPress-site heb je beide nodig.
• Meerdere lagen tegelijk veranderen. Dan weet je niet welke wijziging werkte en is rollback onduidelijk.
• Debugfouten aan bezoekers tonen. Gebruik een beschermd log en houd WP_DEBUG_DISPLAY op productie uit.
• Volledige logs of configuratiebestanden delen. Daarin kunnen wachtwoorden, tokens, persoonsgegevens en serverdetails staan.
• Plugins, thema's of tabellen meteen verwijderen. Deactiveren, hernoemen of een geteste rollback is veiliger.
• Geheugen of uitvoeringstijd onbeperkt verhogen. Daarmee kun je de echte fout verbergen en de server zwaarder belasten.
• Bestandsrechten breed op 777 zetten. Dit vergroot het beveiligingsrisico en herstelt verkeerd eigenaarschap niet betrouwbaar.
• Stoppen zodra één pagina opent. Test ook beheer, foutactie, formulieren, caches en logs.

Hulp nodig bij jouw WordPress-storing?

Stop met zelf wijzigen als je geen herstelbare back-up hebt, de fout server-, proxy- of databasebeheer vereist, of actuele transacties risico lopen. Stuur alleen opgeschoonde foutregels en geef nooit wachtwoorden, cookies of tokens door.

Wil je dat de diagnose, rollback en reparatie gecontroleerd worden uitgevoerd, stuur een WhatsApp-bericht, mail of bel en stel je vraag.