Een tekst aanpassen in WordPress lijkt eenvoudig. Je opent een bericht, verandert een zin en klikt op bijwerken. Toch leerde een recente publicatiewijziging mij opnieuw dat een artikel technisch uit meer bestaat dan alleen de tekst die je op de artikelpagina ziet.
Dezelfde informatie kan terugkomen in de hoofdtekst, de samenvatting, SEO-velden, sociale previews en soms zelfs in gegevens die een thema of plugin apart bewaart. Als je maar één veld aanpast, kan oude informatie elders zichtbaar blijven. Dat maakt een kleine wijziging ineens een interessant automatiseringsvraagstuk.
De zichtbare tekst is maar één gegevensveld
WordPress bewaart de inhoud van een bericht in het inhoudsveld. Daarnaast kan een bericht een handmatige samenvatting hebben. Die samenvatting verschijnt niet altijd op de artikelpagina, maar kan wel worden gebruikt op blogoverzichten, in zoekresultaten binnen de website, in feeds of door een thema.
Daarbovenop kunnen SEO-plugins een aparte titel en beschrijving opslaan. Sociale netwerken kunnen weer andere velden gebruiken voor een gedeelde link. Ook een uitgelichte afbeelding heeft eigen metadata, zoals de alternatieve tekst en het bijschrift.
Voor een bezoeker voelt dit als één artikel. Voor de applicatie is het een verzameling gekoppelde velden met ieder een eigen doel.
Waarom zoeken en vervangen niet genoeg is
Wanneer informatie uit een bericht moet verdwijnen, is alleen zoeken in de hoofdtekst daarom onvoldoende. De artikelpagina kan er na de wijziging goed uitzien, terwijl dezelfde tekst nog op een archiefpagina of in de samenvatting staat.
Andersom wil ik ook niet zonder controle in ieder denkbaar veld dezelfde vervanging uitvoeren. Een woord in de inhoud kan onderdeel zijn van een gewone zin, terwijl het in metadata een andere functie heeft. Blind vervangen maakt automatisering snel, maar niet betrouwbaar.
Mijn voorkeur is dat een systeem eerst inventariseert waar de informatie voorkomt. Daarna moet per veld duidelijk zijn wat wordt aangepast en wat bewust behouden blijft.
Veilige automatisering werkt met kleine acties
Dit sluit aan bij hoe ik websitebeheer met AI opbouw. Ik geef een automatisering liever meerdere kleine, afgebakende mogelijkheden dan één brede opdracht waarmee alles gewijzigd kan worden.
Voor een WordPress-bericht betekent dat bijvoorbeeld afzonderlijke acties voor:
- de volledige artikelinhoud;
- de samenvatting;
- de SEO-titel en metabeschrijving;
- categorieën en tags;
- de uitgelichte afbeelding en bijbehorende tekst;
- de publicatiestatus.
Iedere actie kan vervolgens zijn eigen controles hebben. Welk domein wordt aangepast? Om welk bericht-ID gaat het? Wat is de huidige waarde? Heeft de gebruiker expliciet gevraagd om deze wijziging? En moet de publicatiestatus gelijk blijven?
Die begrenzing lijkt omslachtiger dan één algemene knop, maar maakt fouten veel beter voorspelbaar. Een systeem kan niet per ongeluk een titel of categorie wijzigen als de beschikbare actie alleen de inhoud accepteert.
Een ontbrekende functie is ook een nuttig resultaat
Bij automatisering is de verleiding groot om een omweg te zoeken wanneer een specifieke actie ontbreekt. Dat doe ik juist liever niet. Als een beheerkoppeling wel de hoofdtekst maar niet de samenvatting kan wijzigen, dan is dat geen reden om een bredere of oncontroleerbare route te gebruiken.
Ik leg de ontbrekende mogelijkheid liever expliciet vast. Daarmee ontstaat een concreet bouwvoorstel: voeg een begrensde actie toe waarmee exact één samenvatting kan worden aangepast, controleer vooraf de huidige waarde en verifieer het resultaat achteraf.
Zo wordt een beperking geen losse frustratie, maar input voor een veiligere volgende versie van het systeem.
Controleren in WordPress én aan de voorkant
Na een wijziging controleer ik twee verschillende dingen. Eerst kijk ik of WordPress de nieuwe waarde werkelijk heeft opgeslagen. Daarna controleer ik de openbare pagina alsof ik niet ben ingelogd.
Die controles beantwoorden andere vragen. De WordPress-controle laat zien of de brongegevens kloppen. De publieke controle laat zien of bezoekers het verwachte resultaat krijgen en of de pagina bereikbaar blijft.
Bij wijzigingen in samenvattingen en metadata is ook de context belangrijk. Een samenvatting kan op de losse artikelpagina onzichtbaar zijn, maar wel op het blogoverzicht verschijnen. Een SEO-beschrijving zie je vaak pas in de paginabron of in een specifieke controle. Verificatie moet dus aansluiten op het veld dat is gewijzigd.
Anonimiseren vraagt om veldbewustzijn
Dit wordt extra belangrijk wanneer een naam of andere herkenbare informatie niet meer gepubliceerd mag worden. Dan is “ik zie het niet meer in de tekst” geen sterke eindcontrole.
Een betere controle is:
- zoek de informatie in alle ondersteunde berichtvelden;
- pas alleen de relevante velden gericht aan;
- lees de opgeslagen waarden opnieuw uit;
- controleer de publieke pagina en relevante overzichten;
- meld eerlijk welke velden nog niet door de automatisering worden ondersteund.
Dat laatste punt vind ik essentieel. Een gedeeltelijk geslaagde wijziging mag niet als volledig afgerond worden gepresenteerd. Betrouwbare automatisering rapporteert niet alleen wat goed ging, maar ook wat nog openstaat.
De echte les zit in het datamodel
Wat voor een gebruiker één blogartikel is, bestaat technisch uit meerdere onderdelen. Goede automatisering begrijpt dat verschil. Ze behandelt content niet als één groot tekstblok, maar als een verzameling velden met verschillende gevolgen en rechten.
Dat maakt de uitvoering misschien iets minder spectaculair, maar wel veel professioneler. Het systeem kan preciezer werken, beter uitleggen wat het heeft gedaan en eenvoudiger bewijzen dat het resultaat klopt.
Voor mij is dat de kern: automatisering is pas echt nuttig wanneer ze niet alleen snel wijzigt, maar ook weet welk onderdeel ze wijzigt, wat ze bewust ongemoeid laat en hoe ze het eindresultaat controleert.