SEO-paginagenerator

Probleem

Een lokale landingspagina maken in het CMS is een half uur klikwerk: pagina dupliceren, titel, URL en meta aanpassen, twee tekstblokken herschrijven, de ouderpagina koppelen, opslaan. Voor tientallen steden schaalt dat niet, en wie kopieert en plakt laat structureel een oude stadsnaam ergens in de tekst staan.

Diagnose

Het werk was mechanisch, maar niet simpel. Teksten schrijven kon een model prima; het echte struikelblok zat in de datastructuur van het CMS. Een pagina bestaat daar uit segmenten en blokken die via onderlinge verwijzingen aan elkaar hangen, en zolang die verwijzingen niet klopten kwam er wel een pagina binnen, maar zonder inhoud. Automatiseren betekende dus eerst dat exportformaat doorgronden, en pas daarna tekst genereren.

Aanpak

1. Een zoekterm of een stad invoeren. Een lokaal model bepaalt eerst in welke categorie die term thuishoort.
2. Bij een stadspagina: een bestaande pagina uit het CMS als sjabloon inladen en alle plaatsgebonden teksten vervangen.
3. Bij een zoekterm: zelf de best scorende pagina's erop opzoeken, die uitlezen, en eruit halen waaróp ze scoren.
4. Op basis daarvan de nieuwe teksten laten schrijven tegen een vast schema, met een paar herkansingen als de uitkomst niet aan dat schema voldoet.
5. Het resultaat als importeerbaar bestand terugschrijven en via de beheeromgeving van het CMS importeren, zodat de pagina er echt staat.

Afwegingen

• Alle interne verwijzingen letterlijk overnemen, alleen inhoudsvelden aanraken

  Het CMS gebruikt de onderlinge id's om de structuur van pagina, segment en blok weer op te bouwen. Ze op nul zetten leek de schone oplossing, maar dan importeerde alleen de lege huls en werden alle blokken weggegooid. Het kostte vier ronden onderzoek voordat die regel er lag, en sindsdien is hij hard: id's blijven staan, alleen tekst verandert.

• Importeren via de beheeromgeving, niet via een directe schrijf-aanroep

  Rechtstreeks schrijven was het oorspronkelijke plan. Maar het CMS is een klassiek server-side formulier zonder gedocumenteerde schrijf-API, elke klant draait een eigen versie, en de server doet bij het opslaan dingen die één losse aanroep niet nabootst, zoals het opnieuw genereren van de URL. De route door de beheeromgeving werkte als eerste en is daarna bevroren. De directe route is niet afgeschreven: bij elke run wordt het netwerkverkeer vastgelegd, juist om die later te kunnen bouwen.

• Het gokwerk vooraan zetten, en gratis houden

  Bepalen in welke categorie een zoekterm hoort doet een lokaal model, en dat draait vóór de betaalde stappen. Twijfelt het, dan gaat die ene term naar een paneel waar ik zelf kies, en loopt de rest van de batch gewoon door. Zo kost een twijfelgeval geen credits en houdt hij de rest niet op.

• De generatiemotor bevroren, met één aanroeplaag eromheen

  Toen de pijplijn eenmaal werkte, kostte elke wijziging eraan meer dan hij opleverde. Nieuwe functionaliteit komt sindsdien in de console eromheen, en die mag de motor alleen via één afgesproken laag aanroepen. Wat werkt, blijft werken.

Status en resultaat

Draait in productie en zet pagina's neer die daarna echt live staan. De console laat één klus tegelijk toe, omdat er per CMS maar één sessie open kan staan. De tests zitten bewust op de infrastructuur (opslag, wachtrij, routering, inloggen) en niet op de teksten: het risico zat niet in de schrijfkwaliteit, maar in dubbel draaien, verkeerd doorsturen of half-live achterblijven. De tekstkwaliteit controleer ik met de hand.