CleverTech bouwde de publieke site (businesscenteraltena.nl) als een moderne Next.js 16-website met de aanvraag als kern. Elk aanbod — bedrijfsruimte/kantoorruimte, vergaderruimte, flexwerkplekken, postbus-/vestigingsadres — leidt naar één centrale, server-side lead-flow:
- Contactformulier met een
interestType per aanbod (kantoorruimte, bedrijfsruimte, vergaderruimte, bezichtiging, postbus, flexwerkplek). Elke aanbod-CTA deep-linkt naar het juiste formulier, voorgevuld op de interesse.
- Bezichtigings-wizard in vier stappen (pand(en) kiezen → voorkeursdatum + dagdeel → contactgegevens → bevestiging). De keuze wordt afgevlakt tot één nette aanvraag.
- Beide posten naar één server-side
/api/contact-route: rate-limited per IP, same-origin-check, de organisatie wordt afgeleid uit de hostname (multi-tenant-veilig, nooit uit client-input), Zod-gevalideerd, HTML-escaped, opgeslagen als lead-record en doorgestuurd als e-mail naar het center met de aanvrager als reply-to.
Bewust geen prijzen, geen live voorraadclaim: de productdata zet elke huurprijs op “op aanvraag” en de pagina’s zeggen letterlijk dat er geen voorraadclaim wordt gedaan. Bij het postadres staat de KvK-geschiktheid expliciet “per situatie te beoordelen”. De zorgvuldigheid zit niet in een disclaimer onderaan, maar in de architectuur zelf.
De kern van de vindbaarheid is een getypeerde single-source config (config/altena-seo.ts) die alle 21 officiële kernen van gemeente Altena modelleert (bron: gemeentealtena.nl/gemeente-altena-in-cijfers, als comment in de code). Elke kern krijgt unieke meta-title, meta-description, H1, samenvatting en twee eigen FAQ-vragen.
Het cruciale ontwerpbesluit is de index-modus-splitsing:
- 4 kernen met echte zoekintentie (Werkendam, Woudrichem, Sleeuwijk, Wijk en Aalburg) krijgen een eigen indexeerbare pagina met eigen canonical.
- De andere 17 kernen renderen als verankerde secties op één hub-pagina, met een fragment-canonical terug naar die hub — zo ontstaan geen 17 bijna-identieke doorway-pagina’s.
Slug-collisies zijn bewust afgehandeld (Rijswijk → rijswijk-altena om verwarring met andere Nederlandse Rijswijks te voorkomen; Babyloniënbroek → babylonienbroek). De town-pagina’s draaien op strikte SSG (dynamicParams = false) en zijn Nederlandstalig (anders notFound()).
Diezelfde config bevat ook een route-beslissingstabel die per URL de SEO-dispositie vastlegt (indexeren/redirecten, wel/niet in sitemap, canonical, toegestane en verboden positionering). Één bron stuurt zo de canonicals, de sitemap én de redirects van oude portal-URL’s aan — geen drift.
CleverTech schreef een getypeerde JSON-LD-factory die een samenhangende entity-graph opbouwt: Organization, WebSite, WebPage, BreadcrumbList, ItemList en RealEstateListing, onderling gekoppeld via stabiele @id-referenties (isPartOf/publisher/about/breadcrumb). Lege velden worden weggestript zodat er geen half-gevulde schema wordt uitgestuurd.
Het belangrijkste detail: de RealEstateListing emit bewust alleen naam, URL, omschrijving en afbeelding — geen offers, geen prijs, geen availability. De structured data kan dus per definitie geen beschikbaarheid of prijs verzinnen die de pagina zelf niet toont. Deze waarheidsgarantie is op drie plekken verankerd: in de builder, in de route-beslissingsregels (“verzonnen beschikbaarheid/prijs verboden”) én in de brondata zelf (huurprijs = leeg).
- Consistente NAP (Business Center Altena · De Hoogjens 1, 4254 XV Sleeuwijk · 085 016 0118 · KvK 96122277), bekabeld door de footer (semantisch
<address>-element, met click-tracking) én een locatie-sectie met Google Maps-embed en routebeschrijving.
- nl/en hreflang met
x-default via een gedeelde metadata-helper, plus per-pagina canonicals.
- Build-time OG-afbeeldingen: branded SVG → progressieve JPEG (1200×630) per pagina en taal, gegenereerd met sharp — geen runtime-rendering nodig.
- Force-dynamic sitemap die uit dezelfde route-beslissingstabel put en bij lege database netjes terugvalt op de vier De Hoogjens-panden.
- Robots die de hele afgeschermde portal-laag (dashboard, facturen, documenten, boekingen, …) locale-agnostisch uitsluit, zodat alleen de publieke marketing-surface indexeerbaar is.
De afronding die dit van “gebouwd” naar “continu bewaakt” tilt: een Playwright-test die elke deploy blokkeert. Per commerciële pagina controleert hij: precies één <h1>, één meta-description, één canonical gelijk aan de productie-URL, geen noindex, geldig parsende JSON-LD, en — belangrijk — dat er geen interne SEO-jargon of portal-terminologie naar de zichtbare tekst lekt. Ook de redirects van oude portal-URL’s en de sitemap-hygiëne worden geassert. Zo is de vindbaarheids-structuur geen eenmalige oplevering maar een gegarandeerde eigenschap bij elke release.
