Je wil één ding anders. De knop moet groen, die kop mag kleiner, en die witruimte onder je header is te veel. Vijf minuten werk, denk je. En dat is het ook, tot je thema een update krijgt en alles terug is zoals het was.
Dit is het meest gemaakte fout bij WordPress-design: de juiste wijziging op de verkeerde plek zetten. De webknecht laat zien waar je wijziging thuishoort, en hoe je hem test zonder je live site te gebruiken als proeftuin.
De regel: nooit in het thema zelf
Pas je een bestand aan in de map van je thema, dan overschrijft de volgende update dat bestand. Zonder waarschuwing, want de updater weet niet dat jij daar iets van vindt. Je werk is dan echt weg, niet “even terug te halen”.
Dat geldt ook voor style.css en functions.php van het thema. Precies de twee bestanden waar de meeste mensen als eerste in duiken.
Vier plekken waar je wijziging wel hoort
| Plek | Waarvoor | Let op |
|---|---|---|
| Site-editor of customizer | Kleuren, lettertypes, koppen, menu’s | Altijd eerst kijken of het hier al kan |
| Extra CSS | Kleine visuele correcties | Update-veilig, maar bij tientallen regels onoverzichtelijk |
| Child theme | Templates, layout, echt eigen werk | De enige goede plek voor structurele aanpassingen |
| Snippet of mini-plugin | Functionaliteit die niets met design te maken heeft | Blijft werken als je ooit van thema wisselt |
Dat laatste onderscheid wordt vaak gemist. Een tracking-script of een extra veld bij het afrekenen is geen design. Zet je dat in je thema, dan verdwijnt die functionaliteit zodra je een ander thema kiest.
Een child theme in gewone taal
Een child theme is een map met twee bestanden die tegen WordPress zegt: gebruik dat andere thema, behalve voor de dingen die ik hier neerzet. Je hebt alleen een style.css met een kopregel die naar het moederthema verwijst, en een functions.php.
Vanaf dat moment werkt het zo: zet je een kopie van een templatebestand in je child theme, dan gebruikt WordPress jouw versie. Het moederthema mag rustig updaten, want jouw bestanden staan ergens anders.
De twee klassieke valkuilen: je vergeet de stylesheet van het moederthema netjes in te laden, en je kopieert een half templatebestand waardoor de rest van de pagina wegvalt. Beide zijn precies het soort werk dat je goed kunt laten doen, zolang je de uitkomst controleert.
Testen op preview, niet op je live site
Een layoutwijziging zie je pas kloppen op een echte pagina met echte content. Doe dat dus niet op de site waar je klanten net rondlopen.
Werk je met een hostingaccount waar Claude of Codex aan gekoppeld is, dan krijg je daar een previewomgeving bij op preview.jouwdomein.nl: een kopie van je site, inclusief database, waar je vrij kunt rommelen. Ook screenshots op desktop en mobiel horen erbij, wat prettig is omdat je aanpassing op een telefoon vaak net anders valt. Meer daarover in Invoker Link.
Staat je DNS elders, dan moet je voor die preview zelf een A-record zetten. Kleine drempel, één keer werk.
Versiebeheer is geen luxe voor programmeurs
Zodra je child theme meer dan een paar regels bevat, wil je kunnen terugkijken wat je veranderde. Daar is Git voor, en dat is simpeler dan de reputatie.
In de praktijk koppel je een GitHub-repository aan je hosting en kies je waar hij landt. Voor een thema is dat een submap, niet je hele webroot. Een paar dingen om te weten:
- Bij een private repo krijg je een deploy key. Laat schrijfrechten uit staan, want uitrollen hoeft alleen te lezen.
- Je kiest een branch, meestal
main. Bijwerken kan met de hand of automatisch na elke push via een webhook. - Verwijderde bestanden in je repo verdwijnen niet automatisch van je site. Die moet je zelf opruimen.
- Bestanden die al bestonden en dezelfde naam hebben, worden eerst veiliggesteld voordat ze worden overschreven.
Het grote voordeel: je kunt elke wijziging terugdraaien tot de regel. Dat is meer zekerheid dan een backup je geeft, want een backup zet alles terug, ook het werk dat je wilde houden.
Zo geef je een thema-opdracht die werkt
Laat je het werk doen door Claude, dan is de kunst om het doel te beschrijven en de randvoorwaarden mee te geven. Bijvoorbeeld:
“Maak een child theme voor mijn huidige thema. Zet daarin de knopkleur op #1f6f3d en verklein de koppen op mobiel met 15%. Raak het moederthema niet aan, test op preview en maak een screenshot op desktop en mobiel voordat je zegt dat je klaar bent.”
Drie dingen maken die opdracht goed: de plek staat erin (child theme), de grens staat erin (moederthema niet aanraken) en de controle staat erin (screenshots). Zonder die derde krijg je “gelukt” te horen zonder bewijs. Meer over het aansturen van dit soort tools staat in Claude Code, Codex of Cursor.
Wat je zelf blijft checken
Design is het gebied waar een AI het makkelijkst iets oplevert dat technisch klopt en visueel niet. Loop daarom altijd zelf na:
- Mobiel. Meer dan de helft van je bezoek. Bekijk het op een echte telefoon, niet alleen in een smalle browser.
- Contrast en leesbaarheid. Mooie lichtgrijze tekst op wit is onleesbaar voor een deel van je bezoekers. Zie 10 toegankelijkheids-fixes.
- Snelheid. Een extra lettertype of een zware afbeelding kost je laadtijd.
- De pagina’s die je niet bekeek. Een CSS-regel raakt vaak meer dan één plek.
Werk in kleine stappen, test na elke stap. Eén wijziging terugdraaien is een kwestie van seconden. Twintig wijzigingen tegelijk uitzoeken is een middag.