WordPress-fout oplossen? Wij doen het vandaag nog

Een foutmelding op uw website is bedoeld voor ontwikkelaars, niet voor u. Toch is het nuttig om te weten wat u ziet, al is het maar om ons in één zin te kunnen vertellen wat er aan de hand is. Hieronder de tien meldingen die wij het vaakst tegenkomen, met wat ze in de praktijk betekenen.

1. "Er heeft zich een kritieke fout voorgedaan op deze website." WordPress heeft een fout in de code opgevangen, vrijwel altijd in een plugin of thema, en toont deze melding in plaats van een wit scherm. Meestal staat er een e-mail in de mailbox van de beheerder met de precieze oorzaak.
2. 500 Internal Server Error. De server kon de pagina niet maken. Vaak een fout in de PHP-code, een beschadigd configuratiebestand (.htaccess) of een geheugentekort. De melding zegt niets over de oorzaak; die staat in het foutlogboek van de server.
3. 503 Service Unavailable. De server is tijdelijk overbelast of in onderhoud. Bij WordPress verschijnt deze ook kort tijdens updates. Blijft hij staan, dan zit er vaak een plugin vast of is de hosting te krap.
4. 502 Bad Gateway. De webserver kreeg geen antwoord van de laag erachter, meestal PHP. Vaak een hostingprobleem of een script dat te lang duurt, bijvoorbeeld een zware import.
5. Wit scherm. Helemaal niets, geen tekst. Een fatale PHP-fout waarbij de foutmelding is uitgeschakeld. Oorzaak vrijwel altijd een plugin, thema of te lage geheugenlimiet.
6. "Allowed memory size exhausted". De geheugenlimiet is bereikt. Een plugin of thema vraagt meer dan de hosting toestaat. Vaak op te lossen door de limiet te verhogen of de zware plugin aan te pakken.
7. "Error establishing a database connection". WordPress kan de database niet bereiken. Verkeerde inloggegevens na een verhuizing, een databaseserver die plat ligt, of een beschadigde tabel.
8. Mixed content. De site draait via https, maar laadt nog afbeeldingen of scripts via http. De browser toont geen groen slotje of blokkeert onderdelen. Vaak na een overstap naar SSL zonder dat de oude adressen zijn omgezet.
9. 404 op alle pagina's behalve de homepage. Klassiek na een wijziging van de permalinkstructuur of een verhuizing: het .htaccess-bestand of de serverconfiguratie klopt niet meer met de nieuwe adressen.
10. cURL-fouten en SSL-fouten. "cURL error 28" of "SSL certificate problem": WordPress kan geen verbinding maken met een externe dienst, zoals een betaalprovider of updateserver. Meestal een verlopen certificaat, een firewall of een verouderde server.

Voor al deze meldingen geldt: de melding zelf is een symptoom. Het echte werk is uitzoeken wat erachter zit, en daar gaat de rest van deze pagina over.

Verreweg de meeste WordPress-storingen komen door twee plugins die niet met elkaar overweg kunnen, of door een plugin die niet met het thema of de PHP-versie overweg kan. Beide werkten prima, tot een van de twee werd bijgewerkt. Het diagnosticeren van zo'n conflict is eenvoudig van opzet maar vraagt discipline, want het wordt makkelijk een gokspel.

De methode die wij gebruiken, is uitsluiting. Alle plugins uit, kijken of de fout verdwijnt, en dan één voor één weer aan totdat de fout terugkomt. Klinkt simpel, maar er zijn een paar dingen die het verschil maken tussen een nette diagnose en een ravage:

• Eerst een back-up. Altijd. Ook als het "alleen even uitschakelen" is.
• Bij voorkeur op een kopie van de site. Op de live site plugins uitschakelen betekent dat bezoekers tijdelijk een site zien zonder formulieren, zonder winkelwagen of zonder cookiemelding. Bij een webshop doen wij dit daarom alleen op een stagingomgeving.
• Het foutlogboek erbij. Vaak staat daar al welk bestand de fout veroorzaakt, waardoor het uitsluiten in één stap klaar is in plaats van in twintig.
• Cache leegmaken bij elke stap. Anders kijkt u naar een oude versie van de pagina en trekt u verkeerde conclusies.
• Combinaties niet vergeten. Soms werkt plugin A alleen niet als plugin B ook aan staat. Dan is het geen kwestie van één schuldige maar van een combinatie, en dat vraagt om een andere oplossing.

Als de schuldige is gevonden, zijn er grofweg vier uitwegen. De plugin terugzetten naar de vorige versie, wat tijdelijk werkt maar een beveiligingsrisico kan zijn. Wachten op een update van de ontwikkelaar, wat kan als de functie niet essentieel is. De plugin vervangen door een alternatief. Of de conflictsituatie oplossen met een kleine aanpassing, bijvoorbeeld een instelling of een paar regels code in het child-thema. Welke uitweg het beste is, hangt af van hoe belangrijk de plugin is en hoe snel de ontwikkelaar reageert; wij adviseren daarin en leggen de afweging uit.

Een voorbeeld: een makelaarskantoor kreeg na een update een lege pagina bij het woningaanbod. Het logboek wees op een conflict tussen de plugin voor het woningaanbod en een nieuwe versie van de cacheplugin, die de dynamische lijst als statische pagina opsloeg. Een uitzondering in de cache-instellingen voor die ene pagina loste het op. Geen plugin verwijderd, geen functionaliteit verloren, en de oorzaak is gedocumenteerd voor de volgende update.

De site werkt nog, maar ziet er ineens anders uit: het menu staat verkeerd, de tekst loopt over de afbeeldingen heen, knoppen zijn verdwenen of alles staat onder elkaar op de mobiel. Dit soort fouten geeft geen foutmelding en wordt door monitoring niet opgemerkt, maar bezoekers zien het wel. Bijna altijd is de aanleiding een update van het thema, van de paginabouwer of van WordPress zelf.

De oorzaken die wij het vaakst zien:

• Aanpassingen in het hoofdthema die zijn overschreven. Iemand heeft ooit rechtstreeks in de themabestanden een kleur, een lettertype of een stuk opmaak aangepast. De thema-update zet de originele bestanden terug en de aanpassing is weg. De oplossing is de aanpassing terughalen uit de back-up en verplaatsen naar een child-thema, zodat het niet nog een keer gebeurt.
• Paginabouwer en thema uit de pas. Elementor of Divi is bijgewerkt, maar het thema nog niet, of andersom. De twee verwachten iets anders van elkaar en de opmaak verschuift. Beide bijwerken naar versies die bij elkaar horen lost dit meestal op.
• Verouderde opmaakcode in het thema. Oudere thema's gebruiken technieken die nieuwere browsers of WordPress-versies anders interpreteren. Dan is er een gerichte correctie nodig in de opmaak, of, bij een thema dat niet meer wordt onderhouden, een eerlijk gesprek over de levensduur van de site.
• Cache die oude opmaak vasthoudt. De site is eigenlijk al goed, maar de browser of de cacheplugin toont nog de oude stijlbestanden bij de nieuwe structuur. Cache legen is dan de hele oplossing; wij controleren dit altijd als eerste omdat het zo vaak voorkomt.
• Lettertypen die niet meer laden. Een thema laadt lettertypen van een externe dienst die is veranderd of geblokkeerd, waardoor de site terugvalt op een standaardlettertype en alles net iets anders past.

Wat u zelf kunt controleren voordat u ons belt: open de site in een privévenster van uw browser. Ziet het er daar wel goed uit, dan is het uw eigen browsercache en hoeft er niets te gebeuren. Ziet het er ook daar verkeerd uit, maak dan een schermafbeelding op desktop en op telefoon en stuur die mee; de vergelijking tussen beide zegt ons vaak al waar het zit.

Bij het herstellen van lay-outfouten kijken wij verder dan alleen de pagina die u meldde. Als het menu op de homepage verschoven is, is het waarschijnlijk op alle pagina's verschoven. Wij lopen daarom na de reparatie de belangrijkste pagina's na op desktop, tablet en telefoon, zodat u niet de volgende dag alsnog belt.

"Het formulier werkt niet" betekent in negen van de tien gevallen: het formulier werkt prima, maar de e-mail die het verstuurt, komt niet aan. Dat is een ander probleem met een andere oplossing, en het is er een die wij vrijwel wekelijks oplossen. Omdat de termen die erbij horen afschrikwekkend klinken, leggen wij ze hier in gewone taal uit.

Stel u voor dat uw website een brief verstuurt met als afzender info@uwbedrijf.nl. De postbode, in dit geval de mailserver van de ontvanger, wil weten of die brief echt van u komt. Daarvoor kijkt hij naar drie dingen die bij uw domeinnaam horen:

• SPF is een lijstje bij uw domein waarop staat welke servers namens u mogen mailen. Staat de webserver er niet op, dan is de brief verdacht.
• DKIM is een digitale handtekening onder elke mail. De ontvanger controleert of de handtekening klopt met de sleutel bij uw domein. Zonder handtekening: verdacht.
• DMARC is de instructie wat de ontvanger moet doen als SPF of DKIM niet klopt: toch bezorgen, in de spam zetten of weigeren. Steeds meer ontvangers, waaronder Gmail en Microsoft, eisen dat deze instructie bestaat.

WordPress verstuurt standaard e-mails rechtstreeks vanaf de webserver, zonder handtekening en vaak vanaf een server die niet op uw SPF-lijstje staat. De oplossing heet SMTP: wij laten de website mailen via een echte mailaccount of een e-maildienst, met een gebruikersnaam en wachtwoord, zodat de mail netjes ondertekend en via een vertrouwde server vertrekt. Vervolgens controleren wij de drie instellingen bij uw domein en passen die aan waar nodig. Daarvoor hebben wij meestal toegang nodig tot het beheer van uw domeinnaam; wij leggen precies uit wat er verandert en waarom.

Naast de bezorging zijn er formulierfouten die wél in het formulier zelf zitten. De verzendknop die niets doet, is vaak een JavaScript-conflict met een andere plugin. Een spamfilter dat te streng staat, blokkeert echte klanten. Een verplicht veld dat onzichtbaar is geworden door een lay-outwijziging, maakt verzenden onmogelijk zonder dat de bezoeker begrijpt waarom. En een formulier dat na een update van de formulierenplugin de verkeerde e-mailadressen gebruikt, komt ook voor.

Wat u zelf veilig kunt doen: vul het formulier zelf in met uw eigen e-mailadres en kijk of er iets binnenkomt, ook in de spammap. Controleer daarna in het WordPress-beheer of de inzending is opgeslagen, als uw formulierenplugin dat ondersteunt. Die twee gegevens vertellen ons meteen of het probleem in de bezorging of in het formulier zit.

Bij een webshop kost een fout direct geld. Een checkout die hapert, betekent bezoekers die met een volle winkelwagen afhaken, en die komen zelden terug. Daarom behandelen wij webshopfouten met voorrang en met extra voorzichtigheid: op een webshop schakelen wij nooit zomaar plugins uit om te kijken wat er gebeurt.

De checkout laadt niet of blijft hangen. Meestal een conflict tussen WooCommerce, het thema en een plugin die de checkout aanpast. Sinds WooCommerce is overgestapt op een nieuwe, blokgebaseerde checkout, zien wij dit vaker: oudere plugins verwachten de klassieke versie. Een tijdelijke terugkeer naar de klassieke checkout geeft ruimte om de plugin bij te werken of te vervangen.

iDEAL of een andere betaalmethode ontbreekt of geeft een fout. Bijna altijd de koppeling met de betaalprovider, in Nederland vaak Mollie. Oorzaken: een verlopen of gewijzigde API-sleutel, een betaalmethode die in het Mollie-dashboard is uitgeschakeld, een verkeerde valuta-instelling, of de eerder genoemde cURL/SSL-fout waardoor de webshop de betaalprovider niet kan bereiken. Wij testen dit altijd met een echte testbetaling van een klein bedrag.

Btw klopt niet. Een van de lastigste onderwerpen. Prijzen inclusief of exclusief btw ingevoerd, btw-tarieven per land, het verlaagde tarief voor bepaalde producten, en btw-verlegging voor zakelijke klanten in de EU. Eén verkeerde instelling en de facturen in het boekhoudpakket kloppen niet meer. Wij controleren de instellingen aan de hand van een aantal testbestellingen en leggen de logica vast, zodat u en uw boekhouder weten wat de shop doet.

Verzendkosten worden verkeerd of helemaal niet berekend. Verzendzones die elkaar overlappen, een gewicht dat bij nieuwe producten niet is ingevuld, een gratis-verzendingdrempel die op inclusief btw is ingesteld terwijl de shop exclusief rekent, of een koppeling met PostNL of Sendcloud die de tarieven niet meer ophaalt. De diagnose begint bij één concreet voorbeeld: welk product, naar welk adres, wat verwachtte u en wat zag u.

Voorraad, e-mails en accounts. Bestelbevestigingen die niet aankomen (zie het onderdeel over e-mailbezorging), voorraad die niet wordt bijgewerkt na een bestelling, klanten die niet kunnen inloggen: allemaal zaken die wij dagelijks tegenkomen en die vrijwel altijd met een plugin- of instellingscorrectie zijn op te lossen.

Bij een storing in de checkout starten wij binnen de reactietijd van uw abonnement, of bij een losse opdracht zo snel mogelijk dezelfde werkdag. Voor structurele zorg voor uw webshop is er het WooCommerce-onderhoud, waarbij updates eerst op een testomgeving worden doorgevoerd en de checkout na elke wijziging wordt getest.

Sommige problemen lossen zich in drie minuten op zonder dat er een specialist aan te pas komt. Andere problemen worden aanzienlijk erger door goedbedoelde pogingen. Hieronder staat wat u veilig kunt proberen, en waar u beter van af kunt blijven.

Veilig om zelf te doen:

• De pagina opnieuw laden en in een privévenster bekijken. Als het daar goed gaat, was het uw browsercache.
• De site op een ander apparaat of via mobiele data bekijken. Werkt het daar wel, dan ligt het probleem bij uw netwerk of computer, niet bij de site.
• Vijf minuten wachten bij een 503-melding. Deze verschijnt ook tijdens updates en verdwijnt dan vanzelf.
• De cache van de site legen via de knop van uw cacheplugin in de beheerbalk, als u ingelogd kunt raken. Dit maakt niets kapot.
• Uw e-mail controleren. Bij een kritieke fout stuurt WordPress een bericht naar het beheerdersadres met de oorzaak en een herstellink. Stuur dat bericht naar ons door.
• Een schermafbeelding maken van wat u ziet, inclusief de adresbalk, en noteren wanneer het begon en wat er vlak daarvoor is gebeurd. Dit is het waardevolste wat u kunt aanleveren.

Liever niet zelf doen:

• Plugins verwijderen. Uitschakelen is omkeerbaar, verwijderen niet altijd: sommige plugins wissen hun instellingen en gegevens bij verwijdering.
• Een back-up terugzetten zonder te weten hoe oud die is. Bij een webshop kan dat betekenen dat bestellingen van de afgelopen dagen verdwijnen.
• Bestanden bewerken via de hosting of via de themabewerker in WordPress. Eén ontbrekend haakje en de hele site is onbereikbaar, inclusief het beheer.
• De PHP-versie wijzigen in het hostingpaneel als reactie op een foutmelding. Soms helpt het, vaker maakt het een tweede probleem bovenop het eerste.
• Alle updates tegelijk uitvoeren in de hoop dat het probleem dan verdwijnt. Als het niet werkt, weet niemand meer welke van de twintig updates de boosdoener is.
• Codefragmenten van internet plakken in het functions.php-bestand. Dit is de meest voorkomende manier waarop een klein probleem een wit scherm wordt.

De algemene regel: alles wat u in uw browser doet, is veilig. Alles wat u in de bestanden, de database of de hostingomgeving doet, is dat niet, tenzij u precies weet wat u doet en een back-up heeft. Bij twijfel: niets doen en bellen. Een probleem dat onaangeraakt is, lossen wij sneller op dan een probleem waar al drie dingen aan zijn geprobeerd.

Een fout oplossen is niet hetzelfde als een fout laten verdwijnen. Een plugin uitschakelen laat de melding verdwijnen, maar als u daardoor geen formulier meer heeft, is er niets opgelost. Daarom werken wij volgens een vaste methode, die bij elke storing dezelfde is, ongeacht hoe klein of groot het probleem lijkt.

1. Veiligstellen. Voordat wij iets aanraken, maken wij een volledige back-up van bestanden en database. Als de site gehackt lijkt, isoleren wij bovendien eerst de omgeving, zodat er ondertussen geen verdere schade ontstaat.
2. Reproduceren. Wij proberen de fout zelf te zien: op welke pagina, bij welke handeling, op welk apparaat, ingelogd of niet. Een fout die wij niet kunnen reproduceren, kunnen wij ook niet met zekerheid oplossen.
3. Logboeken lezen. Het PHP-foutlogboek, het serverlogboek en het WordPress-debuglogboek vertellen meestal precies welk bestand op welke regel de fout gaf. Dit slaan wij nooit over; het bespaart uren gokwerk.
4. Tijdlijn vaststellen. Wat is er veranderd vlak voor de fout ontstond? Een update, een nieuwe plugin, een wijziging bij de hosting, een verlopen certificaat? De meeste storingen hebben een aanwijsbare aanleiding.
5. Hypothese testen op staging. Met de informatie uit de vorige stappen hebben wij meestal een sterk vermoeden. Dat testen wij op een kopie van de site, niet op de live site, tenzij de site al offline is en er niets meer te verliezen valt.
6. Oplossen bij de oorzaak. Niet de melding wegwerken, maar het conflict of de fout zelf verhelpen: een plugin bijwerken of vervangen, een instelling corrigeren, een aanpassing verplaatsen naar een child-thema, de geheugenlimiet verhogen.
7. Controleren in de breedte. Na de reparatie lopen wij de belangrijkste pagina's en functies na: homepage, contactformulier, inloggen, en bij een webshop een testbestelling. Een oplossing die iets anders kapotmaakt, is geen oplossing.
8. Documenteren en uitleggen. U krijgt een korte uitleg in gewoon Nederlands: wat de oorzaak was, wat wij hebben gedaan en wat wij adviseren om herhaling te voorkomen.

Hoe lang dit duurt, verschilt. Een kritieke fout door een plugin die het logboek direct aanwijst, is binnen een half uur verholpen. Een btw-berekening die op drie plekken tegelijk verkeerd is ingesteld, kost een paar uur. Wij geven vooraf een inschatting en laten het weten als die niet blijkt te kloppen. Omdat ons technische team vanuit India werkt, kan een storing die u aan het eind van de middag meldt, vaak al 's nachts worden onderzocht en is de site 's ochtends hersteld.

Niemand belt graag een specialist zonder te weten wat het gaat kosten. Daarom werken wij bij bugfixing met een vaste prijs vanaf € 89 exclusief btw voor het oplossen van een fout, en met een duidelijke afspraak over wat daar wel en niet onder valt.

Zo werkt het in de praktijk. U meldt het probleem en wij stellen enkele vragen of kijken kort mee. Binnen een werkdag ontvangt u een inschatting: valt de fout onder het basistarief, of gaat het om een omvangrijker probleem waarvoor wij een vaste prijs afgeven na een korte diagnose. Die diagnose is bij ons niet kosteloos onbeperkt, maar wij rekenen ook geen uren voor een gesprek dat eindigt in "dit kunnen wij niet oplossen". Pas nadat u akkoord bent, beginnen wij aan de reparatie.

Onder het basistarief vallen de meeste veelvoorkomende fouten:

• een kritieke fout of wit scherm door een plugin- of themaconflict;
• een formulier dat niet verzendt of waarvan de e-mails niet aankomen, inclusief SMTP-inrichting;
• 404-fouten na een permalink- of verhuisprobleem;
• mixed content na een overstap naar https;
• een geheugenlimiet- of databaseverbindingsfout;
• een lay-outfout na een update, mits het thema nog wordt onderhouden.

Buiten het basistarief, met een aparte vaste prijs vooraf, vallen onder andere het herstellen van een gehackte site (vanaf € 249 via onze beveiligingsdienst), het oplossen van meerdere onafhankelijke fouten tegelijk, structurele problemen door een thema dat niet meer wordt onderhouden, en fouten in maatwerkcode van een vorige ontwikkelaar die eerst moeten worden ontrafeld.

De garantie is eenvoudig: keert dezelfde fout binnen dertig dagen terug, dan lossen wij die opnieuw op zonder kosten. "Dezelfde fout" betekent dezelfde oorzaak; een nieuwe fout door een nieuwe update is een nieuwe situatie, maar ook daar zijn wij redelijk in. En als wij een probleem niet kunnen oplossen, betaalt u niet. Dat komt zelden voor, maar het hoort bij een eerlijke afspraak.

Voor klanten met een onderhoudsabonnement gelden andere regels: bij Zakelijk en Groei vallen de meeste fouten die ontstaan door updates die wij hebben uitgevoerd, gewoon onder het abonnement. Een overzicht van de losse tarieven en abonnementen vindt u op onze tarievenpagina.

Wat een storing in de praktijk betekent en hoe de oplossing eruitziet, wordt het duidelijkst aan de hand van echte situaties. De onderstaande drie cases zijn geanonimiseerd, maar de details zijn zoals ze waren.

Case 1: het witte scherm van de notaris

Een notariskantoor in Den Bosch belde op maandagochtend: de hele site was wit, ook het beheer. Vrijdagavond had de hostingpartij een e-mail gestuurd dat PHP was verhoogd naar versie 8.2. Het thema van de site dateerde uit 2017 en gebruikte een functie die in PHP 8 niet meer bestaat. Wij zetten de PHP-versie tijdelijk terug naar 7.4, zodat de site binnen tien minuten weer online was. Vervolgens maakten wij op staging een child-thema met een correctie voor de verouderde functie, testten de site op PHP 8.2 en zetten de wijziging live. Totale doorlooptijd: één werkdag. Advies aan de klant: het thema nadert het einde van zijn levensduur; wij hebben de risico's uitgelegd, maar de keuze om te vernieuwen ligt bij hen.

Case 2: de bestellingen die niet betaald konden worden

Een webshop in kinderkleding merkte op een zaterdagmiddag dat klanten bij het afrekenen de melding "betaalmethode niet beschikbaar" kregen. iDEAL ontbrak volledig. De monitoring had niets gezien, want de site was gewoon online. Onze diagnose wees op een cURL-fout: de webshop kon de servers van Mollie niet bereiken doordat de hostingpartij een verouderd certificaatpakket had. Wij konden dat aan onze kant tijdelijk omzeilen en hebben de hostingpartij gevraagd het pakket bij te werken, wat maandag gebeurde. Zaterdagavond werkte iDEAL weer. Uit het logboek bleek dat de fout al vrijdagmiddag was begonnen: anderhalve dag zonder betalingen, in een weekend met een actie.

Case 3: de formulieren die drie maanden niemand bereikten

Een installatiebedrijf vroeg ons waarom het "zo rustig" was met aanvragen. Het contactformulier stuurde netjes een bedankje, maar de e-mails werden door Microsoft 365 geweigerd omdat de webserver niet in het SPF-record stond en er geen DMARC-beleid was. Wij richtten SMTP in via hun eigen Microsoft-account, corrigeerden SPF en DKIM, en stelden een DMARC-beleid in. Uit de opgeslagen inzendingen in de formulierenplugin konden wij 41 gemiste aanvragen terughalen, waarvan de klant er alsnog een aantal heeft kunnen opvolgen. De reparatie zelf kostte minder dan twee uur; de schade van drie maanden zwijgen was aanzienlijk groter.

De rode draad in alle drie: de fout was niet ingewikkeld, maar hij werd te laat opgemerkt. Wilt u weten hoe uw site ervoor staat, dan is een gratis websitecheck een goed begin.

Een aparte categorie fouten ontstaat wanneer de adressen van uw pagina's veranderen: na een verhuizing naar een andere hostingpartij, een overstap van http naar https, een wijziging van de domeinnaam of een aanpassing van de permalinkstructuur. De site staat dan wel, maar bezoekers, Google en uw eigen links komen uit op pagina's die niet meer bestaan.

Het bekendste symptoom is de 404 op alle pagina's behalve de homepage. WordPress bepaalt met behulp van een klein bestand (.htaccess op Apache-servers) of met serverregels (op Nginx) hoe adressen als uwbedrijf.nl/diensten worden vertaald naar de juiste pagina. Bij een verhuizing of een permalinkwijziging wordt dat bestand soms niet meegenomen of niet herschreven. De reparatie is vaak simpel, maar het diagnosticeren vereist dat u weet waar u moet kijken.

Andere adresproblemen die wij regelmatig oplossen:

• Mixed content na https. De site is beveiligd, maar in de database staan nog duizenden verwijzingen naar http-adressen van afbeeldingen. Wij vervangen die in één keer in de database, inclusief de verwijzingen in paginabouwers die hun gegevens in een speciaal formaat opslaan en daarom niet met een simpele zoek-en-vervang kunnen worden aangepast.
• Doorverwijzingslussen. De site verwijst van http naar https, en de hosting verwijst van https naar http, of het domein met www verwijst naar zonder www en terug. De browser geeft na een aantal rondjes op. Meestal een dubbele instelling in WordPress, een plugin en het hostingpaneel.
• Oude adressen na een herstructurering. Pagina's zijn hernoemd of verplaatst, maar de oude adressen worden nog gebruikt in Google, in nieuwsbrieven en op andere websites. Zonder doorverwijzingen krijgt elke bezoeker via zo'n link een 404. Wij richten doorverwijzingen in van elk oud adres naar het juiste nieuwe adres.
• Afbeeldingen die na een verhuizing ontbreken. De database verwijst naar de oude servernaam of het oude pad; de bestanden staan er wel, maar op een andere plek. Ook dit is een database-correctie.

Wat u zelf kunt controleren: open een willekeurige pagina van uw site via een link uit Google in plaats van via het menu. Komt u op een 404-pagina uit, dan is er waarschijnlijk meer aan de hand dan die ene pagina. Kijk ook naar het slotje in de adresbalk: staat er een waarschuwing of ontbreekt het slotje op sommige pagina's, dan is er mixed content.

Verhuist u binnenkort van hosting, dan raden wij aan de verhuizing door een specialist te laten doen; wij verzorgen die voor een vast tarief en controleren daarna alle adressen. Het kost minder dan het herstellen van een verhuizing die halverwege is misgegaan.

Een fout oplossen is het halve werk. De andere helft is zorgen dat dezelfde fout niet over twee maanden terugkomt. In onze ervaring komt een storing bijna nooit "uit het niets"; er is een onderliggende oorzaak die bij de reparatie zichtbaar wordt. Die benoemen wij in de uitleg die u van ons krijgt, en waar het binnen de opdracht past, pakken wij hem meteen aan.

De maatregelen die wij het vaakst adviseren of uitvoeren na een reparatie:

• Een child-thema aanmaken als aanpassingen rechtstreeks in het hoofdthema stonden, zodat de volgende thema-update niets wist.
• Automatische updates uitschakelen voor plugins waarvan bekend is dat ze conflicten geven, en die voortaan handmatig en met controle bijwerken.
• Een stagingomgeving inrichten voor webshops en grotere sites, zodat updates eerst op een kopie worden getest.
• De geheugenlimiet en PHP-versie op orde brengen, zodat de site niet op het randje van de hostingcapaciteit draait.
• Verouderde en niet-onderhouden plugins vervangen voordat ze bij de volgende PHP- of WordPress-update problemen geven.
• SMTP en de domeininstellingen vastleggen zodat e-mail vanaf de site structureel aankomt, niet alleen vandaag.
• Monitoring aanzetten op de pagina's die er echt toe doen, inclusief de checkout, zodat een storing binnen minuten en niet binnen dagen wordt opgemerkt.
• Documenteren wat er is veranderd en waarom, zodat een volgende beheerder of een collega van ons niet opnieuw hoeft te zoeken.

Een eerlijk woord over de grens tussen bugfixing en onderhoud. Wie elke paar maanden een losse reparatie nodig heeft, betaalt uiteindelijk meer dan wie de site structureel laat onderhouden, en heeft daarbij ook nog de storingen zelf. Wij zeggen dat niet om een abonnement te verkopen, maar omdat het rekenkundig zo is: drie losse reparaties per jaar kosten ongeveer evenveel als vier maanden Basis-abonnement, waarin die storingen waarschijnlijk niet waren ontstaan. Wilt u na een reparatie de site structureel bijhouden, dan kan dat via een onderhoudsabonnement, maandelijks opzegbaar en zonder opstartkosten. Wilt u alleen de fout opgelost hebben, dan is dat net zo goed prima; wij helpen u graag opnieuw als het nodig is.

Heeft u nu een storing? Stuur een bericht met een schermafbeelding en het adres van de pagina, of bel tijdens kantooruren. Wij laten binnen een werkdag weten wat er aan de hand is en wat de oplossing kost.