Je voegt eigen code toe aan een door AI gemaakte website op twee manieren, afhankelijk van hoeveel controle je wilt. Binnen de builder zelf kun je meestal een blok voor eigen code of een embed plaatsen, goed voor een script, een widget of een stuk HTML. Wil je echte controle, dan exporteer je het project naar een repository zoals GitHub en bewerk je de code in een echte editor, waar je componenten, routes en logica toevoegt. Het uitgangspunt achter beide is hetzelfde: een door AI gemaakte site is gewone code, geen gesloten systeem, dus je bent niet vastgezet op wat de builder voorziet. Breng je inhoud of componenten uit WordPress mee, exporteer die dan eerst schoon. WPBuildAI scant de site en levert de inhoud als schone Markdown met componenten, routes en metadata, klaar om in het project te zetten.

Een AI-site is gewone code

Het helpt om te beginnen bij wat een AI-builder eigenlijk maakt, want dat bepaalt je opties. Onder de visuele editor genereert de builder echte code: HTML, CSS en JavaScript, vaak in de vorm van een modern project met componenten. Dat betekent dat je eigen code geen vreemd element is dat de site niet aankan, maar gewoon meer van hetzelfde. De vraag is dus niet of je code kunt toevoegen, maar waar: binnen de builder, met zijn ingebouwde mogelijkheden, of buiten de builder, in de geexporteerde code. Welke je kiest, hangt af van hoe diep je ingreep gaat.

Manier 1: een blok voor eigen code in de builder

Voor een afgebakende toevoeging blijf je in de builder. De meeste AI-builders hebben een blok voor eigen code of een embed-element waarin je HTML, een script of een widget van derden plakt. Dat is genoeg voor een analytics-script, een chatwidget, een formulier van een externe dienst of een klein stukje opmaak. Het voordeel is dat je niets hoeft te exporteren en de site in de builder beheerd blijft. De grens is dat je beperkt bent tot wat zo’n blok toelaat: voor diepe ingrepen in de structuur of eigen routes schiet het tekort, en dan is de tweede manier op zijn plaats.

Manier 2: exporteer naar een repository en bewerk in een editor

Wil je volle controle, dan haal je het project uit de builder. Veel AI-builders kunnen de code exporteren naar een repository zoals GitHub, en vanaf daar bewerk je alles in een echte editor: eigen componenten, routes, build-stappen en logica. Dit is dezelfde route als bestaande WordPress-code in een AI-builder importeren, maar omgekeerd: je neemt de gegenereerde code als startpunt en bouwt erop verder. Het voordeel is onbeperkte controle; de afweging is dat je daarna doorgaans buiten de visuele builder werkt, met een eigen deploy. Voor wie echt wil programmeren, is dit de manier.

Inhoud uit WordPress meenemen

Komt je inhoud uit WordPress, dan voeg je naast code ook content toe, en die moet schoon binnenkomen. Exporteer de pagina’s en berichten als schone Markdown, los van de WordPress-thema-opmaak, zodat ze in de componenten van het project passen. Heb je live data nodig, dan kan de site die uit WordPress lezen via de WordPress REST API, de aanpak uit een AI-builder koppelen aan de headless WordPress-API. Behandel afbeeldingen als inhoud, niet als bijzaak: het Web Almanac 2024 laat zien hoeveel een pagina aan media draagt, dus neem ze mee en werk de paden bij.

Houd het in versiebeheer

Zodra je eigen code toevoegt, wordt versiebeheer belangrijk, of je nu in de builder of in een editor werkt. Zet het geexporteerde project onder Git, zodat elke wijziging terug te draaien is en je weet wat er veranderde toen iets brak. Binnen de builder is dat lastiger, want een codeblok heeft geen geschiedenis; daarom is voor alles wat verder gaat dan een los script de export naar een repository veiliger. Het idee is simpel: eigen code is iets dat je onderhoudt, en onderhoud zonder geschiedenis is gokken. Een repository geeft je die geschiedenis en maakt samenwerken mogelijk.

Let op de prestaties van wat je toevoegt

Eigen code is krachtig, maar elke regel die je toevoegt heeft een prijs in snelheid. Een extra script, een zware widget of een grote bibliotheek vertraagt het laden, en snelheid telt mee in de Core Web Vitals die web.dev beschrijft. Laad daarom alleen wat je echt nodig hebt, plaats scripts zo dat ze het tonen van de pagina niet blokkeren, en meet de impact na elke toevoeging. Dit geldt extra voor scripts van derden, die je niet zelf in de hand hebt. Een AI-site begint vaak snel; het is wat je toevoegt dat de snelheid maakt of breekt, dus voeg bewust toe.

Stap voor stap

  1. Bepaal de diepte: een los script, of structurele code.
  2. Klein: gebruik een blok voor eigen code of een embed in de builder.
  3. Groot: exporteer het project naar een repository.
  4. Bewerk in een editor: voeg componenten, routes en logica toe.
  5. Breng WordPress-inhoud schoon mee als Markdown.
  6. Houd het in versiebeheer en meet de prestaties na elke toevoeging.

Voorbeeld: een eigen component toevoegen

Neem een team met een marketingsite uit een AI-builder dat een eigen prijscalculator wil, iets wat een codeblok niet aankan. Eerst probeert het de kleine weg, maar de calculator heeft eigen logica en state nodig, dus het exporteert het project naar GitHub. In een editor wordt de calculator als component toegevoegd, naast de bestaande code van de builder. De inhoud uit de oude WordPress-site komt als schone Markdown mee, met bijgewerkte afbeeldingspaden. Alles staat onder Git, zodat elke stap terug te draaien is. Na een meting van de laadtijd, die binnen de Vitals blijft, gaat de site live. De calculator werkt, en de rest van de site bleef zoals de builder hem maakte.

De grenzen om te kennen

Eigen code toevoegen heeft grenzen die je beter vooraf kent. Werk je buiten de builder verder, dan kun je meestal niet zomaar terug naar de visuele editor zonder je wijzigingen te verliezen, dus dat is een keuze met gevolgen. Updates van de builder zelf bereiken je geexporteerde project niet meer. En was de site al live, dan moet je de URLs bewaken: behoud ze waar het kan, en zet anders een 301, volgens de richtlijn voor site verplaatsen met URL-wijzigingen. Geen van deze grenzen is blokkerend, maar elk is een bewuste afweging in plaats van een verrassing achteraf.

Veelgemaakte fouten

  • Een structurele ingreep in een codeblok proppen waar een export nodig is.
  • Geexporteerde code zonder versiebeheer bewerken.
  • Zware scripts toevoegen zonder de laadtijd te meten.
  • Inhoud uit WordPress als rommelige HTML meeslepen in plaats van schone Markdown.
  • Bij een live site URLs laten wijzigen zonder 301.

Wat je moet onthouden

Je voegt eigen code toe aan een door AI gemaakte website op twee manieren: een blok voor eigen code in de builder voor een script of widget, of het project exporteren naar een repository en bewerken in een echte editor voor volle controle. Een AI-site is gewone code, dus je bent niet vastgezet. Kies de eerste manier voor losse toevoegingen en de tweede voor structurele, breng inhoud uit WordPress schoon mee als Markdown, houd alles in versiebeheer en meet de prestaties van wat je toevoegt. WPBuildAI scant de site en levert de inhoud als schone Markdown met componenten, routes en metadata, klaar om in het project te zetten. Stuur je site-URL voor een gratis analyse.

Geen connectie met WordPress, Lovable, Webflow, Shopify, Wix of Squarespace.