SEO voor een digitaal product: het begint lang voor je je eerste artikel schrijft

Wanneer we met een klant een nieuwe website voor zijn product bespreken, begint het gesprek bijna nooit met SEO.

Het begint met het product:

• Wat bouwen we eigenlijk?

• Voor wie is het?

• Welke problemen lost het op?

• Wat maakt het anders dan de twaalf concurrenten die al op de markt zijn?

• Hoe zou iemand eigenlijk zoeken naar een oplossing als deze?

Interessant genoeg verandert productontwikkeling ergens tijdens dat gesprek langzaam in SEO zonder dat iemand het echt merkt.

• Kunnen we echt doen wat deze pagina belooft?

• Moeten we deze feature bouwen voordat we erover schrijven?

• Heeft iemand die naar deze term zoekt een probleem dat ons product echt oplost?

Die vragen klinken als productontwikkelingsvragen, want dat zijn het ook. Het interessante is dat het ook SEO-vragen zijn.

Veel bedrijven zien SEO nog steeds als iets wat na de ontwikkeling gebeurt. Het product is af, marketing komt erbij, iemand doet keywordonderzoek, er worden een paar landingspagina's geschreven en met een beetje geluk begint Google bezoekers te sturen.

Persoonlijk vind ik die volgorde omgekeerd.

Bij We Do Dev Work beschouwen we SEO altijd als een onderdeel van productontwikkeling. Niet omdat developers plots marketeers moeten worden, maar omdat beide disciplines vertrekken van precies dezelfde vraag: wat proberen mensen te bereiken?

Of je nu software bouwt of content schrijft, je probeert iemands probleem te begrijpen voordat je een oplossing voorstelt.

Productonderzoek en SEO-onderzoek zijn bijna dezelfde oefening

Stel dat je software bouwt voor boekhouders.

Voor je één regel code schrijft, stel je waarschijnlijk vragen als:

• Wat frustreert boekhouders vandaag?

• Welke tools gebruiken ze nu?

• Wat kost te veel tijd?

• In welke sectoren komen deze problemen het vaakst voor?

• Welke features zouden genoeg verschil maken om over te stappen?

Een SEO-specialist zou bijna identieke vragen moeten stellen.

In plaats van te vragen welke feature ontwikkeltijd verdient, vragen ze welk probleem een landingspagina verdient. In plaats van een productbacklog te prioriteren, prioriteren ze contentkansen. Het onderliggende onderzoek is echter opvallend gelijk.

Daarom willen we productontwikkeling en SEO niet scheiden in twee totaal verschillende projecten. Ze moeten elkaar voortdurend beïnvloeden.

Je product moet je content bepalen

Een van de grootste fouten die we zien, is dat bedrijven content maken voor functionaliteit die ze niet echt aanbieden.

Een keywordtool suggereert een zoekterm met een degelijk zoekvolume, iemand schrijft er een landingspagina rond en plots suggereert de website dat de software features ondersteunt die niet bestaan of maar gedeeltelijk geïmplementeerd zijn.

Dat kan op korte termijn verkeer opleveren, maar het zorgt voor teleurgestelde bezoekers, lagere conversie en uiteindelijk vertrouwensschade.

Wij pakken het liever omgekeerd aan: elke betekenisvolle feature moet vanzelf contentkansen creëren.

Heb je offertebeheer gebouwd, dan kun je uitleggen hoe offertes verschillen van facturen, hoe offerteworkflows werken, welke veelgemaakte fouten bedrijven maken en waarom digitale offertes tijd besparen.

Heb je ondersteuning voor meerdere valuta toegevoegd, dan zijn er voor de hand liggende kansen om internationale facturatie, wisselkoersen en grensoverschrijdende betalingen uit te leggen.

Heb je je gespecialiseerd in een bepaalde sector, dan verdient dat eigen landingspagina's die uitleggen hoe je software de problemen van die sector oplost.

Merk op wat hier gebeurt: het product volgt de content niet, de content volgt het product.

Zoekgedrag is waardevolle productfeedback

De relatie werkt ook in de andere richting.

Keywordonderzoek zou je marketingteam niet alleen moeten vertellen wat het moet schrijven. Het zou je productteam ook moeten vertellen waar mensen naar op zoek zijn.

Als honderden of duizenden potentiële klanten blijven zoeken naar een feature die je software niet heeft, is dat waardevolle informatie.

Soms is de juiste conclusie niet om nog een artikel te schrijven over waarom je het niet ondersteunt. Zet het gewoon op de roadmap.

Goed SEO-onderzoek brengt vaak onvervulde klantbehoeften aan het licht lang voordat ze in een verkoopgesprek opduiken.

SEO wordt opnieuw technischer

Mensen verdelen SEO vaak in technische SEO en content-SEO, maar wij zien technische SEO steeds meer gewoon als onderdeel van het bouwen van een goede webapplicatie.

Even op een rij:

• Snelle websites bieden een betere gebruikerservaring.

• Logische navigatie helpt bezoekers informatie makkelijker te vinden.

• Duidelijke interne links leggen het verband tussen verschillende onderwerpen uit.

• Gestructureerde data helpt zoekmachines je content te begrijpen.

• Een degelijke meertalige architectuur voorkomt problemen met dubbele content en zorgt dat de juiste taal aan het juiste publiek getoond wordt.

Geen van deze verbeteringen doen we voor Google. We bouwen websites en applicaties voor mensen. Waarom geven we er dan om? Simpel: ze verbeteren de kwaliteit van de website zelf.

Als je website makkelijker te begrijpen wordt voor zoekmachines, wordt hij meestal ook makkelijker voor bezoekers.

Wat is er veranderd met AI?

Om de paar maanden verschijnt er een nieuwe kop die aankondigt dat SEO fundamenteel veranderd is.

Dit jaar draait het gesprek rond AI-zoekopdrachten, Generative Engine Optimisation (GEO), llms.txt-bestanden en het optimaliseren van content voor grote taalmodellen.

Die ontwikkelingen zijn echt en het loont de moeite er aandacht aan te besteden. We houden tijdens de ontwikkeling al rekening met zaken als gestructureerde content, schema markup, nette documentatie en een voor AI leesbare websitearchitectuur, omdat het verstandige technische beslissingen zijn.

Tegelijk denken we niet dat AI de fundamenten veranderd heeft:

• AI heeft nog steeds betrouwbare informatie nodig

• Het heeft nog steeds baat bij goed gestructureerde websites

• Het verkiest nog steeds content die echte vragen beantwoordt

Misschien is de grootste verandering dat consistentie nog belangrijker is dan voorheen. Je landingspagina's, documentatie, helpcentrum en product moeten allemaal hetzelfde verhaal vertellen. Als je website features belooft die je software niet levert, is die inconsistentie veel makkelijker te detecteren, of het nu door een zoekmachine is, een AI-model of, belangrijker nog, een potentiële klant.

Wat Google zegt over AI Overviews

Google documenteert dit rechtstreeks. Om als ondersteunende link te verschijnen in AI Overviews of AI Mode moet een pagina geïndexeerd zijn en in aanmerking komen om met een snippet in Search te verschijnen, en Google stelt dat er "no additional requirements" zijn en geen "special optimizations necessary". Je hebt geen nieuwe machineleesbare bestanden, AI-tekstbestanden of markup nodig, en ook geen speciale schema.org gestructureerde data. Dat geldt ook voor llms.txt: Google vraagt er niet om. Opname is nog steeds niet gegarandeerd.

Wat Google wel aanraadt, is gewone goede praktijk: laat crawlers toe, link pagina's intern zodat ze makkelijk te vinden zijn, houd belangrijke content als tekst en zorg dat gestructureerde data overeenkomt met de zichtbare pagina. Verkeer van deze features wordt geteld in het zoektype Web van het prestatierapport in Search Console, zodat je het kunt meten zonder nieuwe tool. Andere AI-assistenten gedragen zich misschien anders, maar we hebben nog geen reden gezien om een tweede site voor hen te bouwen.

SEO integreren in productontwikkeling

In plaats van SEO als de laatste fase van een project te behandelen, bespreken we het liever tijdens de hele ontwikkeling.

Telkens als we een nieuwe feature ontwerpen, stellen we onszelf vanzelf een aantal extra vragen.

Product

• Welk klantprobleem lost dit op?

• Is dat probleem belangrijk genoeg dat mensen actief naar een oplossing zoeken?

• Welke terminologie gebruiken klanten om het te beschrijven?

• Welke sectoren of gebruikersgroepen ervaren dit probleem het vaakst?

Content

• Verdient deze feature een eigen landingspagina?

• Kunnen we ondersteunende documentatie of FAQ's schrijven?

• Zijn er blogonderwerpen die logisch voortvloeien uit deze functionaliteit?

• Kunnen we de feature demonstreren met screenshots of echte voorbeelden?

Technische SEO

• Past dit logisch binnen de websitearchitectuur?

• Versterkt het onze interne links?

• Hebben we gestructureerde data nodig?

• Is het beschikbaar in elke ondersteunde taal?

• Kunnen zoekmachines en AI-systemen de pagina makkelijk begrijpen?

Tegen de tijd dat een feature in productie gaat, is het meeste SEO-denkwerk al gebeurd.

Het artikel schrijven is vaak het makkelijkste deel.

Zoekintentie bepaalt welk soort pagina je nodig hebt

Vraag je voor je een keyword kiest af wat de persoon die het intikt wil. Hetzelfde product kan in heel verschillende stemmingen gezocht worden, en elke stemming vraagt een andere pagina.

Onze gids beste softwareontwikkelingsbedrijven in Thailand is een voorbeeld van een pagina met koopintentie: de lezer vergelijkt al opties, dus geeft ze criteria, een shortlist en prijzen in plaats van een definitie van outsourcing. Als je paginatype niet bij de intentie past, lost geen enkele optimalisatie dat op. Googles eigen starter guide raadt aan na te denken over de woorden die een gebruiker zou kunnen zoeken, en merkt op dat mensen met verschillende kennisniveaus dezelfde behoefte anders formuleren.

Doe keywordonderzoek voor je bouwt

De meeste teams doen keywordonderzoek wanneer de site af is. Doe het wanneer de roadmap nog open is, want het kan de roadmap veranderen.

1. Som de problemen op, niet de features. Gebruik de woorden die klanten gebruiken in verkoopgesprekken en supporttickets.
2. Zoek zelf elk probleem op. Kijk wie er rankt en welke paginatypes verschijnen. Als elk resultaat een vergelijking is en jij een featurepagina plant, heb je het verkeerde formaat.
3. Check je eigen data. Search Console toont de zoekopdrachten waarvoor je al vertoningen krijgt, het goedkoopste onderzoek dat je ooit zult doen.
4. Sorteer de bevindingen in drie stapels: dingen die we doen en waarover we zouden moeten schrijven, dingen die we doen maar waar niemand naar zoekt, en dingen waar mensen naar zoeken en die we niet doen. De derde stapel is productfeedback; zie hierboven.
5. Valideer voor je bouwt. Een landingspagina voor een geplande feature, duidelijk gemarkeerd als "binnenkort", is een goedkope test van de vraag. Beschrijf haar nooit als beschikbaar.

Plan de informatiearchitectuur vroeg

Sitestructuur is een productbeslissing. Googles SEO starter guide raadt aan de site logisch te organiseren, beschrijvende URL's te gebruiken met woorden die gebruikers helpen in plaats van willekeurige identifiers, en pagina's te linken met beschrijvende ankertekst. Ze merkt ook op dat de meeste nieuwe pagina's die Google elke dag ontdekt via links gevonden worden.

Een structuur die voor de meeste digitale producten werkt:

• Hubpagina's voor elk hoofdprobleem of elke doelgroep (bijvoorbeeld "software voor boekhouders").
• Spokepagina's eronder: features, use cases, vergelijkingen, how-to-gidsen, elk met een link terug naar de hub en zijwaarts naar verwante spokes.
• Eén URL per onderwerp. Als twee pagina's dezelfde vraag beantwoorden, voeg ze samen.
• Dezelfde structuur in elke taal, zodat vertaalde pagina's niet wees blijven. De technische kant hiervan komt aan bod in SEO voor developers.

Contenttypes die vaak ranken en converteren

• Vergelijkingspagina's ("X vs Y", "alternatieven voor X"). Lezers staan dicht bij een beslissing. Wees eerlijk; een vergelijking waarin jouw product altijd wint overtuigt niemand. Wij volgen dit patroon in Python vs Node.js en .NET vs Java.
• Probleemgidsen die één vraag volledig oplossen, met stappen die iemand vandaag kan volgen.
• FAQ's geschreven vanuit echte vragen van sales en support, geplaatst op de pagina waar de vraag opkomt, niet op een stortplaatspagina.
• Prijs- en kostenpagina's. "Hoeveel kost het" is een van de meest voorkomende kopersvragen; zie onze eigen uitsplitsing websitekosten in Thailand en de prijzen.
• Tools en rekenmachines die een vraag rechtstreeks beantwoorden. Onze EngineeringScore-audit en de migratiegidsen van MigrateXtoY begonnen als producten en trekken ook mensen aan met precies die behoefte.
• Casestudy's met echte cijfers, zoals onze Shopify-appcase.

Googles richtlijnen voor people-first content vragen of de content originele informatie, onderzoek of analyse biedt, duidelijke bronvermelding toont en wie het schreef, en verder gaat dan samenvatten wat anderen zeggen. Een pagina gebouwd op je echte productervaring doorstaat die test veel makkelijker dan een herschrijving van de top tien resultaten.

Programmatic pages: nuttig op schaal, of spam op schaal

Veel pagina's genereren uit data kan legitiem zijn. Denk aan één pagina per stad, per integratie, per sector of per migratiepad. Het gaat mis wanneer de pagina's enkel verschillen door een verwisseld keyword.

Googles spamrichtlijnen definiëren scaled content abuse als veel pagina's gegenereerd "for the primary purpose of manipulating search rankings", en zeggen dat het probleem grote hoeveelheden onoriginele content met weinig waarde is, "no matter how it's created". Generatieve AI gebruiken om veel pagina's te maken zonder waarde toe te voegen is een vermeld voorbeeld. Doorway abuse is het maken van "substantially similar pages" om te ranken voor vergelijkbare zoekopdrachten in plaats van een duidelijk gedefinieerde, doorbladerbare hiërarchie.

Onze regels voordat we een reeks pagina's op basis van een template genereren:

• Bevat elke pagina data of advies dat waar en specifiek is voor die pagina? Als je enkel de plaatsnaam kunt wijzigen, publiceer het dan niet.
• Zou een bezoeker die erop landt een echt antwoord vinden, geen trechter naar een andere pagina?
• Maakt ze deel uit van de normale navigatie van de site en is ze gelinkt vanuit een hub?
• Kun je beginnen met 10 sterke pagina's en de resultaten bekijken voor je er 1,000 maakt?

MigrateXtoY is een nuttig voorbeeld van de goede versie: elke migratie tussen twee platformen heeft eigen stappen, een inspanningsschatting en valkuilen, zodat elke pagina inhoudelijk verschilt. Google noemt ook het aanpassen van paginadatums om er vers uit te zien, zonder substantiële updates, als teken van content die op zoekmachines is gericht, dus doe dat ook niet.

Welke aanpak moet je kiezen?

• Vóór de lancering, geen publiek: doe keyword- en intentieonderzoek, bouw dan de hubpagina's en 5 tot 10 pagina's met koopintentie en probleempagina's. Sla volume over.
• Live product, weinig verkeer: check Search Console, repareer pagina's die vertoningen maar geen klikken krijgen, voeg vergelijkings- en prijspagina's toe.
• Veel gelijkaardige aanbiedingen (steden, sectoren, integraties): een programmatic set is gerechtvaardigd, maar enkel met unieke data per pagina.
• Bezorgd over AI-zoekopdrachten: doe de fundamenten hierboven, houd belangrijke content als crawlbare tekst en meet in Search Console. Koop geen "AI-optimalisatiepakket" dat iets belooft wat volgens Google niet vereist is.

Wil je snel zien waar je huidige site technisch staat, haal hem dan door EngineeringScore (gratis) of gebruik onze websitecheck. Voor hulp bij het plannen van een productsite, bekijk onze projecten of de prijzen.

Wat is de boodschap hier

Mensen vragen ons vaak of SEO door marketing, developers of een extern bureau moet gebeuren. Ons antwoord is meestal "alle drie", zolang ze samenwerken.

• Marketing begrijpt positionering

• Developers begrijpen het product

• Designers begrijpen gebruiksvriendelijkheid

SEO zit ergens in het midden van die disciplines.

Hoe beter die teams samenwerken, hoe natuurlijker je website wordt. In plaats van pagina's te schrijven omdat een keywordtool ze suggereerde, documenteer je echte functionaliteit, beantwoord je echte klantvragen en bouw je autoriteit op rond het product dat je gemaakt hebt.

Daarom zien we SEO niet als iets wat je toevoegt na de lancering van een website.

We zien het als iets wat begint op het moment dat je over het product zelf begint na te denken.

Bronnen

• https://developers.google.com/search/docs/appearance/ai-features
• https://developers.google.com/search/docs/essentials/spam-policies
• https://developers.google.com/search/docs/fundamentals/creating-helpful-content
• https://developers.google.com/search/docs/fundamentals/seo-starter-guide