Een Strato WordPress-omgeving komt vaak binnen bij ons met dezelfde symptomen: het beheerscherm voelt stroperig, updates blijven halverwege hangen, en niemand weet meer via welke weg de site ooit is geïnstalleerd. Dat ligt zelden aan de hoster als zodanig. Het ligt aan de combinatie van standaardinstellingen, een installatiewizard en jaren zonder beheer.

Hieronder de punten die wij het vaakst tegenkomen, met per punt hoe u nagaat of het bij u speelt. Voorwaarden en pakketten wijzigen regelmatig, dus controleer de details in uw eigen beheeromgeving.

De installatie via de wizard

Grote hosters bieden een knop waarmee u WordPress in één klik neerzet. Handig, maar zo’n installatie wijkt vaak af van een handmatige. Er staan soms extra plugins in, de mappenstructuur kan afwijken, en updates worden op een eigen manier afgehandeld.

Het gevolg merkt u pas later: u werkt de kern bij vanuit het beheerscherm, terwijl de hosting daar zelf ook iets mee doet. Of u wilt de site verhuizen en ontdekt dat de installatie in een submap staat met een doorverwijzing eroverheen.

Nagaan of dit speelt: kijk in het bestandsbeheer of de WordPress-bestanden direct in de openbare map staan of een niveau dieper. Kijk daarnaast in de pluginlijst of er iets staat wat u niet zelf heeft geïnstalleerd. Vindt u dat, verwijder het niet meteen; zoek eerst uit of de hosting het gebruikt.

Een PHP-versie die jaren blijft staan

Dit is de meest voorkomende vondst. De versie is ooit ingesteld bij het aanmaken van het pakket en daarna nooit meer aangeraakt. Sites die op 7.4 draaien komen wij nog steeds tegen, en dat is een versie die al geruime tijd geen beveiligingsherstel meer krijgt.

Het lastige is dat de site gewoon werkt. Er is geen waarschuwing en geen foutmelding, dus niemand doet iets. Tot een plugin een nieuwere versie vereist en de site na een update stukloopt.

Verhoog stapsgewijs en test na elke stap. Maak vooraf een back-up en houd de knop bij de hand om terug te zetten. Kunt u de versie niet zelf kiezen in het paneel, dan zit u op een pakket dat voor WordPress te beperkt is.

Een database die niet mee is verhuisd

Bij internationale pakketten staat de database soms op een andere machine dan de bestanden. Dat werkt prima, maar het maakt elke databasevraag iets trager. Bij een site met een paginabouwer die honderden opvragingen per pagina doet, telt dat op tot een merkbare vertraging.

Herkenbaar aan één ding: de tijd tot het eerste antwoord van de server is hoog, ook op een simpele pagina, terwijl het laden daarna vlot gaat. Meet dat op twee momenten van de dag, want een eenmalige uitschieter zegt weinig.

Wat helpt: paginacaching aanzetten zodat lang niet elke bezoeker de database raakt, de database opschonen van oude revisies en verlopen tijdelijke gegevens, en kritisch kijken naar plugins die op elke pagina meedraaien terwijl ze maar op één pagina nodig zijn.

Mail die niet aankomt

Formulieren die stilletjes niets doorsturen zijn de duurste storing die er bestaat, want u merkt het pas als een klant belt. Bij veel hosters wordt mail die WordPress zelf verstuurt slecht afgeleverd, omdat het afzenderadres niet overeenkomt met wat er in de DNS-instellingen is vastgelegd.

De oplossing is bij elke hoster hetzelfde: verstuur uw formuliermail niet via de standaardfunctie van PHP, maar via een echte mailserver met een gebruikersnaam en wachtwoord. Dat is een kwestie van een plugin en tien minuten instellen. Hoe dat werkt staat in het stappenplan voor het instellen van SMTP in WordPress.

Test daarna vanaf een adres buiten uw eigen domein, bijvoorbeeld een privéadres, en kijk ook in de map ongewenste post. Een test naar uzelf op hetzelfde domein zegt niets.

Back-ups waar u niet zelf bij kunt

Er staat vrijwel altijd een back-upvoorziening in het pakket. Wat u moet nagaan: hoe ver gaat hij terug, kunt u er zelf bij zonder een verzoek in te dienen, en zet hij alles tegelijk terug of ook losse onderdelen?

Terugzetten van alles tegelijk is bij een webshop een probleem. U herstelt dan wel de fout van gisteren, maar u gooit ook de bestellingen van vandaag weg. Zorg dat u de database los kunt terugzetten van de bestanden, of dat u in elk geval eerst een kopie van de huidige stand maakt.

Zet er daarnaast een eigen regeling naast die naar een opslag buiten de hosting schrijft. Dat is niet uit wantrouwen, maar omdat de meeste sites niet stukgaan door een serverstoring maar door een verkeerde handeling of een besmetting die pas weken later opvalt.

WordPress bij Strato houden of toch overstappen?

De eerlijke conclusie: voor een gewone bedrijfssite is een internationaal gedeeld pakket prima, mits u de PHP-versie bijhoudt, caching gebruikt en uw mail fatsoenlijk verstuurt. Verhuizen levert dan weinig op en kost u een dagdeel plus het risico op een verkeerd gezette verwijzing.

Overstappen wordt wel verstandig als u drie dingen ziet: u kunt de PHP-versie niet zelf instellen, de tijd tot het eerste antwoord blijft na caching boven de anderhalve seconde, en de ondersteuning geeft geen antwoord op inhoudelijke vragen. Bij een webshop weegt dat zwaarder dan bij een informatieve site.

Denkt u aan een verhuizing, doe het dan buiten kantooruren, houd de oude omgeving nog twee weken online en verlaag de wachttijd op uw DNS-instellingen ruim van tevoren. De volgorde staat in het stappenplan voor verhuizen naar een andere hosting.

Blijft u zitten, dan is de maandelijkse controle het enige wat er structureel bij komt. Wilt u die niet zelf doen, dan kunt u er vast beheer met updates en controle achteraf omheen laten hangen zonder van hostingpartij te wisselen; bij WebMaintor is dat de meest gekozen route.

Concrete volgende stap: kijk in uw hostingpaneel welke PHP-versie er draait en stuur uzelf vanaf een extern adres een bericht via uw contactformulier. Die twee controles kosten vijf minuten en dekken de twee duurste valkuilen af.