Webontwikkeling

Webontwikkeling die zowel zoekmachines als klanten kunnen lezen

Wij bouwen websites en webapplicaties in React en Next.js — server-rendered, gemeten langs de Core Web Vitals, en zo opgebouwd dat Google elke pagina kan indexeren die voor u telt.

Waarom veel bureausites stilletjes onderpresteren

Een groot deel van de sites die wij moeten redden deelt één grondoorzaak: ze zijn gebouwd als single-page JavaScript-applicatie. De server stuurt een vrijwel leeg HTML-document terug en de inhoud verschijnt pas nadat de browser de bundel heeft gedownload en uitgevoerd. Voor degene die de site heeft laten maken ziet de pagina er prima uit. Voor een crawler bij de eerste passage is het een blanco pagina met een laadicoon.

Het tweede patroon is subtieler. De site wordt wel op de server gerenderd, maar elke route deelt dezelfde titel en beschrijving, er is geen interne linkstructuur buiten de hoofdnavigatie, en het hele bedrijf is samengeperst tot één scrollende homepage. Google heeft precies één document om mee te werken, dus de site kan alleen meedingen naar één zoekopdracht — tegen organisaties met honderden geïndexeerde pagina's.

Beide problemen zijn architectonisch. Geen enkele hoeveelheid sleutelen aan zoekwoorden lost er één van op, en daarom kunnen sites in deze toestand jarenlang vlak blijven terwijl de eigenaar zijn metabeschrijvingen blijft herschrijven.

Wat een traject bij ons omvat

Standaard server-rendered

Pagina's worden op de server naar HTML gerenderd en statisch gegenereerd waar de inhoud dat toelaat. Het eerste antwoord bevat al uw koppen, teksten en gestructureerde data, dus een crawler hoeft geen JavaScript uit te voeren om de pagina te begrijpen — en een bezoeker op een trage verbinding ziet inhoud in plaats van een laadscherm.

Een echte URL voor elk onderwerp

Elke dienst, locatie, artikel en case krijgt een eigen route, een eigen titel en beschrijving, en een eigen plaats in de interne linkstructuur. Dit is de grootste hefboom op het aantal zoekopdrachten waarop een site kan verschijnen, en die keuze valt bij het ontwerp van de architectuur, niet achteraf.

Core Web Vitals als bouwrandvoorwaarde

Wij begroten Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift tijdens de ontwikkeling in plaats van achteraf te profileren. In de praktijk betekent dat: afbeeldingen met expliciete afmetingen, zelf gehoste en vooraf geladen lettertypen, en client-side JavaScript dat bewust wordt toegevoegd in plaats van standaard.

Gestructureerde data die bij de pagina past

Organization-, Breadcrumb-, Service-, Article- en FAQ-schema, gegenereerd uit dezelfde inhoud die de pagina toont. Omdat het is afgeleid en niet met de hand geschreven, kan het niet uit de pas lopen met wat een bezoeker werkelijk ziet — precies de voorwaarde die Google stelt aan rich results.

Een contentmodel dat u zelf kunt bewerken

Inhoud staat in een getypeerde datalaag of een headless CMS, niet hard gecodeerd in componenten. Een dienstenpagina toevoegen of een artikel publiceren vraagt geen ontwikkelaar, en de sjablonen garanderen dat de nieuwe pagina meteen met correcte metadata en schema aankomt.

De repository, bij oplevering

U krijgt de code, de deployconfiguratie en de documentatie. De hosting is van u. Wij hebben er geen belang bij een klant vast te houden met infrastructuur die hij niet kan verlaten.

Technologie die wij hiervoor gebruiken

Framework

  • Next.js
  • React
  • TypeScript

Ook gebruikt

  • Angular
  • Vue.js

Styling

  • Tailwind CSS
  • Design tokens
  • CSS Modules

Content

  • Payload CMS
  • WordPress (headless)
  • Getypeerde contentlaag

Uitlevering

  • Vercel
  • Docker
  • GitHub Actions
  • Azure

Wij kiezen hieruit op basis van wat het project nodig heeft en wat uw team na de overdracht kan onderhouden — niet op basis van waar wij het liefst mee werken. Ligt er al een gezonde technische basis, dan werken wij daarbinnen.

Projecten waarvoor dit geschikt is

Marketingsites die moeten scoren

Waar organisch zoekverkeer een echt acquisitiekanaal is en geen vinkje, telt de informatiearchitectuur zwaarder dan het visuele ontwerp. Wij bepalen de URL-structuur en interne links voordat er aan de interface wordt gewerkt.

Een trage of onindexeerbare site vervangen

Migraties waarbij de bestaande site een client-rendered SPA is, of snel in een labtest en traag voor echte gebruikers. Wij brengen elke bestaande URL naar zijn vervanger en houden 301-redirects in stand, zodat opgebouwde rankingsignalen de verhuizing overleven.

Webapplicaties voor klanten

Dashboards, portalen en boekingssystemen waarbij de ingelogde applicatie achter een marketingsite zit die nog steeds crawlbaar moet zijn. Beide hebben tegengestelde renderingeisen en kunnen het beste als zodanig worden behandeld.

Meertalige uitrol

Sites voor meerdere landen, waarbij elke taal een eigen indexeerbare URL en een correcte hreflang-set nodig heeft. Vier talen vanaf één URL serveren op basis van browserheaders is een veelvoorkomende en kostbare fout — crawlers sturen altijd maar één taal mee.

Vragen die ons hierover worden gesteld

Hoe lang duurt het bouwen van een website?

Een gerichte marketingsite met een vastgelegde set pagina's duurt doorgaans 4 tot 8 weken vanaf de start. Webapplicaties met authenticatie, koppelingen of eigen werkprocessen lopen meestal 8 tot 16 weken. Wij werken in fasen en geven een vaste prijs per fase in plaats van een open uurregeling.

Scoort de site na livegang in Google?

Wij kunnen de voorwaarden scheppen die scoren mogelijk maken: indexeerbare pagina's, een schone architectuur, snelle laadtijden, kloppende gestructureerde data en zinnige interne links. Posities kunnen wij niet beloven, en wees voorzichtig met wie dat wel doet. Rankings hangen af van de concurrentie, de autoriteit van uw site en Google's eigen systemen — geen daarvan staat onder controle van welk bureau dan ook. Wat wij wel toezeggen: technisch zal niets op de site de site tegenhouden.

Werkt u met een bestaande codebase?

Ja. Een flink deel van ons werk is het overnemen van projecten die door iemand anders zijn gebouwd. Wij beginnen met een korte audit, zodat u een eerlijk beeld krijgt: is de bestaande code het uitbreiden waard, of is opnieuw bouwen over elke realistische termijn goedkoper?

Wie is eigenaar van de code?

U, vanaf de eerste commit. Wij ontwikkelen in uw repository als u er een heeft, of leveren aan het einde van de opdracht een complete repository op met deploydocumentatie.

Kunt u samenwerken met onze eigen ontwikkelaars?

Regelmatig. Dat kan betekenen dat wij een afgebakend deel van het systeem beheren, code reviewen, of een periode naast uw team meedraaien. Wij nemen uw conventies en branchingmodel over in plaats van de onze op te leggen.

Denkt u aan webontwikkeling?

Stuur ons het probleem en de beperkingen die u al kent. Wij komen terug met wat wij denken dat het vraagt, een aanpak en een realistische orde van grootte — of met de mededeling dat wij hier niet de juiste partij voor zijn.

Begin een gesprek