WordPress audit checklist: de tol van je Elementor-stack

Het is woensdag, 11:40 's ochtends. De marketing lead bij een Utrechts ingenieursbureau opent haar urenstaat voor augustus en telt nog een keer. Veertien uur, tegen WordPress, in een maand waarin er niets aan de site zou veranderen. Drie van die uren gingen op aan het terugdraaien van een WP Rocket-update die de Elementor Pro-header op de Nederlandse site sloopte maar niet op de Engelse. Twee gingen op aan een WPML string translation-klusje dat twintig minuten had moeten kosten. De rest is de trage rot van een zes jaar oude stack die niemand erg genoeg haat om te vervangen en niemand graag genoeg mag om te verdedigen.

We zien dit patroon op ongeveer de helft van de Nederlandse MKB-sites die we auditten tussen vijf en vijftien miljoen omzet. De estate is altijd een of andere smaak van WordPress 6.5 plus Elementor Pro plus WP Rocket plus WPML, op een shared host met zevenenveertig plugins, waarvan de lead er drie niet herkent. De site converteert nog steeds. De kosten zitten verstopt in een marketingsalaris.

Deze post is de audit die wij draaien voordat we iets aanraken. Het is een halve middag werk en hij beantwoordt drie vragen: wat gaat elke plugin-update breken, waar zit de content vastgepind in de builder, en welke pagina's overleven een rebuild zonder je Google Ads-kwaliteitsscore tot de grond toe te verbranden.

Het lek van veertien uur

Het getal is consistent genoeg om bruikbaar te zijn. Wanneer een marketing lead meer dan tien uur per maand op een WordPress-estate schrijft, zit het lek bijna altijd op dezelfde drie plekken.

De eerste is de interactie tussen Elementor en WP Rocket. De "remove unused CSS"-functie van WP Rocket stuurt de stylesheet van elke Elementor-widget via een andere pipeline naar de browser dan de rest van het thema. Na een point release van Elementor Pro raakt die pipeline verouderd, klapt de header op mobiel in, en moet iemand of de cache of de rebuild-CSS-toggle uitzetten tot WP Rocket een compatibility-update uitbrengt. Dit gebeurt ongeveer elke zes weken.

De tweede zijn de vertaaltabellen van WPML. WPML slaat post-vertalingen op in wp_icl_translations met foreign keys die wijzen naar wp_posts. Wanneer een redacteur een Nederlandse pagina verwijdert via de admin UI, blijven de Engelse en Duitse kopieën achter, maar verliezen ze hun parent reference. Ze duiken zes maanden later op in een sitemap-audit waar niemand om vroeg.

De derde is de plugin-updatequeue zelf. Een typische mid-size estate heeft tussen de dertig en vijftig actieve plugins. Twee of drie zijn verlaten. Eén is een betaalde Elementor add-on die in veertien maanden geen release heeft uitgebracht. De lead weet dit en klikt niet op "update all" omdat ze haar vingers heeft gebrand, dus de queue groeit tot iemand 'm in paniek leegt zodra er een CVE valt.

De audit zet dit lek om in een lijst die iemand in een sprint kan oplossen.

Plugin-update blast radius

We scoren elke actieve plugin op een schaal van 0 tot 3 over vier assen. De output is één getal per plugin: de blast radius.

• Oppervlak. Raakt de plugin templates, het database-schema, of beide? Een caching-plugin scoort 3. Een SEO meta box scoort 1.
• Update-cadans. Heeft de plugin in de afgelopen 90 dagen een release uitgebracht? Een stilstaande plugin scoort 3, want niemand heeft 'm tegen de huidige WordPress getest.
• Hook-diepte. Hangt de plugin in the_content, pre_get_posts, of de REST API? Diepe hooks scoren 3, want een regressie in een van die filters cascadeert geluidloos.
• Vervangbaarheid. Als de plugin morgen verdwijnt, hoeveel uur kost het om 'm te vervangen? Onder de twee scoort 0. Boven de veertig scoort 3.

De blast radius is de som. Alles dat 8 of hoger scoort krijgt een regel in het rebuild-grootboek. Alles dat 11 of 12 scoort is de plugin die je niet aanraakt tot je een staging-kloon hebt en een met de hand uitgeschreven rollback-plan.

Een snelle manier om de lijst met actieve plugins en hun laatste-update-tijdstempels vanaf de command line te dumpen, mits je WP-CLI op de server hebt:

wp plugin list --status=active --fields=name,version,update,update_version \
  --format=csv > active-plugins.csv

# Cross-reference against the .org repository for last-commit date
for slug in $(wp plugin list --status=active --field=name); do
  curl -s "https://api.wordpress.org/plugins/info/1.0/${slug}.json" \
    | jq -r "[\"$slug\", .last_updated, .tested] | @csv"
done > plugin-freshness.csv

Premium plugins (Elementor Pro, WP Rocket, WPML) verschijnen niet in de .org API. Daarvoor checken we het vendor-changelog met de hand. Voor de hele estate kost dat twintig minuten, en het brengt elke licentie boven water die is verlopen zonder dat iemand het merkte.

Custom post type lock-in

Dit is het deel van de audit dat bepaalt of een rebuild een refactor wordt of een volledige migratie.

Elke Elementor Pro-template is opgeslagen als een custom post type (elementor_library). De pagina-content zelf wordt geserialiseerd in een _elementor_data post meta-veld, als één JSON-blob. Die blob verwijst naar widget-ID's die alleen betekenis hebben als Elementor Pro is geladen. Strip de plugin en de pagina rendert als een muur lege divs.

Hetzelfde patroon geldt voor de meeste builder-plugins en voor een handvol CRM-plugins (HubSpot, ActiveCampaign) die form-definities in custom tabellen opslaan. WPML voegt zijn eigen laag toe: elke vertaalde post is een aparte rij in wp_posts, gelinkt via wp_icl_translations, terwijl string-vertalingen in een derde tabel staan met zijn eigen backup-model.

De auditstap is mechanisch. Voor elke custom post type tel je drie dingen:

-- Posts that depend on Elementor for rendering
SELECT COUNT(*) AS elementor_locked
FROM wp_posts p
JOIN wp_postmeta m ON m.post_id = p.ID
WHERE p.post_status = 'publish'
  AND m.meta_key = '_elementor_data'
  AND m.meta_value LIKE '%"widgetType"%';

-- Posts in custom post types defined by plugins (not the theme)
SELECT post_type, COUNT(*) AS n
FROM wp_posts
WHERE post_status = 'publish'
  AND post_type NOT IN ('post', 'page', 'attachment', 'revision', 'nav_menu_item')
GROUP BY post_type
ORDER BY n DESC;

-- WPML translation pairs that have lost their reference
SELECT t.element_type, COUNT(*) AS orphans
FROM wp_icl_translations t
LEFT JOIN wp_posts p ON p.ID = t.element_id
WHERE t.element_type LIKE 'post_%'
  AND p.ID IS NULL
GROUP BY t.element_type;

De output van die derde query is degene die klanten verrast. We zien tussen de 40 en 600 wezen-rijen op een typische mid-size site. Ze breken vandaag niets. Ze breken wel het migratiescript als je niet weet dat ze er zijn.

De drie-pagina-overlevingstest

Hier is de test die bepaalt of een gedeeltelijke rebuild het risico waard is. Kies de drie pagina's die het meeste betaalde verkeer trekken. Meestal zijn dat de homepage, één servicepagina, en één landingspagina die aan een actieve Google Ads-campagne hangt. Beantwoord voor elke pagina vier vragen op papier, niet op een slide.

1. Wat is de URL-slug, en hangt er nog iets anders op de site aan vast? AdWords-bestemmings-URL's, e-mailhandtekeningen, gedrukte brochures en Google Business-profielen pinnen slugs hard vast. Als de slug verandert, zijn redirects geen optie.
2. Wat is de H1, de meta title en de schema-markup? Deze drie samen sturen de landing page experience-score aan die de Google Ads-kwaliteitsscore voedt. Google's documentatie over landing page experience is expliciet dat de relevantie van de bestemming en de laadtijd de rating domineren.
3. Welke plugins heeft de pagina daadwerkelijk nodig om te renderen? Open de pagina, bekijk de source, en deactiveer in een staging-kloon elke plugin één voor één. Als de pagina het zonder Elementor overleeft, is de helft van je migratieprobleem opgelost. Zo niet, noteer welke widgets ze gebruikt.
4. Wat is het formulier, en waar gaan de submissions heen? Een landingspagina zonder werkend formulier is erger dan geen landingspagina. We hebben rebuilds zien live gaan met het contactformulier dat wees naar een CRM-endpoint dat al twee jaar deprecated was.

Een pagina die alle vier de vragen doorstaat kan headless worden herbouwd (Next.js, Astro, Eleventy, wat dan ook) in een week, zonder AdWords-performance te verliezen. Een pagina die vraag drie niet doorstaat heeft een builder-afhankelijkheid die een content-migratie nodig heeft voordat de URL kan verhuizen. Een pagina die vraag vier niet doorstaat vraagt om een meeting met degene die de CRM beheert, voordat er ook maar iets anders gebeurt.

AdWords-landingsslot conserveren

Dit is de regel die we elke klant vertellen en waar bijna elke klant tegenin wil gaan: verander de URL van een actieve Google Ads-landingspagina niet tijdens een rebuild. Niet de slug, niet het protocol, niet de trailing slash. De kwaliteitsscore wordt deels berekend op historische CTR voor die exacte bestemmings-URL, en een 301-redirect zet de klok op die historie terug op nul. Google heeft dit nooit direct bevestigd. Elke paid search-lead met wie we de afgelopen tien jaar hebben gewerkt heeft hetzelfde litteken.

De implicatie voor de audit is simpel. De drie landings-URL's met de hoogste mediabesteding zijn onverplaatsbaar. De rebuild serveert ofwel hetzelfde pad via de nieuwe stack (een reverse proxy voor de oude WordPress-installatie, of een statische export met overeenkomende slugs), ofwel hij raakt die URL's helemaal niet aan. Al het andere ligt op tafel.

Check meteen ook de canonical tag. WPML heeft de gewoonte om de canonical naar de standaardtaalversie te laten wijzen, ook als de bezoeker via een betaalde ad op een vertaalde URL landde. Dat is een van de weinige auditbevindingen die binnen dertig dagen meetbaar omzet kost.

De audit op één middag draaien

De hele audit past in een halve dag als je admin-toegang en een staging-kloon hebt. De deliverable is één spreadsheet met drie tabs: plugin blast radius, custom post type-inventaris, en het drie-pagina-overlevingsblad. Daarbovenop sturen we de klant een samenvatting van één pagina met het kerngetal: de geprojecteerde maandelijkse uren na de rebuild.

Op een zes jaar oude estate is de enige schaalbare opschoning een schone installatie van WordPress 6.5 (Shirley, uitgebracht in april 2024) met de content geïmporteerd via een gecureerde export, niet een database-dump. Een dump sleept elke wezen-vertaalrij mee, elke options-entry van een verlopen plugin, en elke WPML-join die je tijdens de audit hebt geïdentificeerd. Een gecureerde export betekent een gedefinieerde post type allow-list, een meta-key allow-list, en een media-folder-pass die de wezen-uploads uit 2019 dropt. Minder dan dat houdt het lek in stand.

Toen we deze audit afgelopen voorjaar draaiden voor een Rotterdams logistiek bedrijf, had de WPML-estate 312 wezen-vertaalrijen en een Elementor Pro-licentie die elf maanden eerder was verlopen. We hebben drie pagina's headless herbouwd op een Next.js front-end, WordPress aangehouden als redactionele back-end voor de rest, en de WordPress-uren van de marketing lead zakten naar twee per maand. Dit werk valt onder wat we normaal een legacy migratie noemen, en de audit is het goedkope deel. Bij de rebuild draait het om discipline.

Kies de drie URL's waar je het bangst voor bent ze te verliezen. Open ze in drie browsertabs. Als je niet uit je hoofd kunt noemen welke plugins elke pagina nodig heeft om te renderen, begint je audit daar.