Academy

Een website bouwen is lastig. Een SEO-vriendelijke website bouwen is nóg lastiger. Het gebeurt maar al te vaak dat een development team elkaar feliciteren na een gigantisch project, maar dan blijkt dat de website niet aan de hedendaagse SEO standaarden voldoet.

Er zijn veel redenen waarom dit gebeurt. De vier meest voorkomende zijn:

  1. Het development team was niet juist gebriefd.
  2. Het development team was niet goed getraind in SEO door de SEO specialisten.
  3. De SEO specialisten werden té laat in het proces pas betrokken.
  4. Het development team dacht dat ze “SEO” onder de knie hadden.

Requirements engineering - uitvinden wat je moet bouwen - is een echte kunst en is essentieel voor het succes van elk (web)development project.

Als je niet weet wat de projectdoelstellingen zijn, wat je moet bouwen en welke standaarden je moet volgen - hoe kun je dan van het project een succes maken, en precies bouwen wat jouw klant wil?

In dit artikel hebben we het over alle SEO vereisten die je moet overwegen wanneer je een nieuwe website bouwt of verder gaat met het bouwen van een bestaande website. Het is nuttig voor alle betrokkenen: de klant die een nieuwe website wil, SEO specialisten die ervoor moeten zorgen dat de website SEO proof is, en web development bedrijven die uiteindelijk de website bouwen.

Ondanks dat er veel lijsten online te vinden zijn met de SEO vereisten van een website wordt er vaak één factor vergeten: de concurrentie en prioriteiten per vereiste. Vaak zijn er voor veel vereisten ook andere oplossingen. Een robots.txt hoeft niet perse in het CMS bewerkbaar te zijn als er maar server toegang is bijvoorbeeld. Kijk naar hetgeen de concurrentie doet: hebben deze allemaal een snelle website, dan zou dit wellicht een hogere prioriteit moeten hebben dan andere specificaties. Voor een Marktplaats gelden echt andere prioriteiten dan voor de bakker op de hoek.

Jordy Noll
Jordy Noll

Hoewel je als SEO-specialist natuurlijk vanaf dag één een perfecte SEO-site live wilt zien, gaat het in de praktijk zelden zo voorspoedig. Vaak genoeg sta je voor dilemma’s waarbij je keuzes moet maken tussen features die essentieel zijn om te hebben vóór livegang en wat kan wachten tot erna. Definieer dus bij je lijst met requirements of een onderdeel essentieel is of niet. Prioriteer vervolgens de requirements die niet essentieel zijn. Let wel: lage prioriteit requirements kunnen al snel afgedaan worden als “niet nu”, en vervolgens ergens op een vaak lange backlog eindigen.

Tenslotte: audit de huidige website op basis van de opgestelde requirements, zodat je weet of het uitstellen van bepaalde requirements niet eventueel leidt tot een minder geoptimaliseerde site op dat gebied.

Roy Huiskes
Roy Huiskes

De eerste vraag die je moet stellen is of de site opnieuw gebouwd wordt, of ‘as-is’ blijft. Bij een ‘as-is’ situatie verbeter je de bestaande situatie. Je schrijft bijvoorbeeld op basis van de bestaande stories. Bij een helemaal nieuwe situatie heb ik een relatief standaard document dat in het kort de belangrijkste aandachtspunten aanstipt. Bij elk item staat vooral de achterliggende gedacht uitgelegd en waar developers meer informatie kunnen vinden (vooral de Google Developer Guidelines). Daarnaast zet ik altijd een voorbeeld hoe dit voor de klant toe te passen is.

Het belangrijkste in beide gevallen is dat de stakeholders, front-end en back-end developers en UX-designers weten waarom bepaalde zaken voor SEO zo gedaan worden. Dit zorgt ervoor dat we allemaal hetzelfde doel hebben en niemand het gevoel heeft dat de SEO op hun stoel gaat zitten.

Daarnaast geef ik altijd aan dat alle requirements die ik aangeeft moeten worden doorgevoerd. Low priority requirements daar geloof ik niet in. Op voorhand weet je dat die er niet gaan komen, beter doe je dat later in een continue optimalisatie proces en bespaar je iedereen de moeite.

Happy Search Engine Robot

Wanneer betrek je SEO specialisten erbij?

SEO specialisten moeten betrokken zijn vóór, tijdens, en na het bouwen van een nieuwe website. Het is belangrijk ze op de hoogte te houden tijdens het bouwen van nieuwe websites en als er iets wordt veranderd.

Dus: in het geval van een nieuw website development project, betrek SEOs erbij van het allereerste begin. Waarom? Omdat de SEO vereisten voor de nieuwe website een grote invloed op de prijs van de website hebben.

Te vaak worden SEO specialisten veel te laat bij het development proces betrokken. Ze komen er dan al snel achter dat de website niet SEO-proof is en dus maken ze een lijst met SEO vereisten waar dan weer extra budget voor nodig is. Dit leidt tot een onoverzichtelijke project flow, hogere kosten en vertragingen. Allemaal dingen waar de klant niet blij van wordt.

Laten we nu eens de mouwen opstropen, en verder gaan met de daadwerkelijke SEO vereisten.

No-brainers

Alle vereisten in deze sectie spreken eigenlijk voor zich. Ze zijn al jaren de industriestandaard, dus zullen ze niet echt een verrassing zijn.

Responsive design

Een responsive design betekent dat het ontwerp zich aanpast aan het apparaat waarop het gebruikt wordt. Responsive designs zijn fantastisch voor zowel bezoekers als zoekmachine crawlers. Het bezorgt bezoekers een consistente ervaring op jouw website, onafhankelijk van welk apparaat ze gebruiken. Zoekmachine crawlers - en vooral Google - waarderen websites die bezoekers een goede mobiele ervaring geven. De achterliggende reden is dat eind 2015 het aantal mobiele zoekopdrachten het aantal desktop zoekopdrachten overtrof. Het is dus belangrijk dat jouw website ook een goede ervaring aan bezoekers vanaf een mobiel apparaat geeft.

Responsive designs maken het ook makkelijker voor SEO specialisten, want ze hoeven maar één URL per pagina te promoten. In het verleden had je een aparte desktop en mobiele site waarnaar gelinkt werd vanaf andere websites en moest je deze link en relevantie signalen consolideren. Dit was altijd minder optimaal in vergelijking met links vanaf één URL.

Lees verder over

Accelerated Mobile Pages

Als je voor een uitgever aan een website werkt, dan zul je moeten overwegen of je Accelerated Mobile Pages (AMP) wilt implementeren. We raden het niet aan om AMP voor een ander type website te implementeren.

AMP is een open-source initiatief en formaat van Google wat het doel heeft om de ervaring voor mobiele gebruikers te versnellen. AMP pagina’s zijn uitgeklede versies van pagina’s die dan geoptimaliseerd worden om snel te laden op mobiele apparaten.

Waarom is AMP alleen nuttig voor uitgevers? Aangezien het ervoor zorgt dat je in Google News carrousel opgenomen wordt. En dit levert een hoop verkeer op! Maar andere types van websites kunnen hier niet van profiteren, en dan wegen de nadelen niet op tegen de voordelen.

Lees verder over AMP

HTTPS

HTTPS staat voor Hyper Text Transfer Protocol Secure. Het is de veilige versie van HTTP, het protocol dat wordt gebruikt om de data en de website die je bezoekt te versturen. Wanneer je HTTPS gebruikt, is het moeilijker voor anderen om mee te kijken met wat je doet.

Google wil graag dat websites HTTPS gebruiken, en heeft het daarom een kleine ranking factor gemaakt. Terwijl het misschien iets helpt, geeft het je niet echt een groot voordeel ten opzichte van de concurrentie op het gebied van SEO. Om het te ondersteunen laten ze “Not Secure” zien in de URL van websites die formulieren bevatten en die niet HTTPS gebruiken.

Hier is een voorbeeld:

Vandaag de dag is HTTPS een moetje. Dus elke website die wordt gebouwd moet worden aangeboden via HTTPS. Daarom checkt ContentKing of websites beschikbaar zijn via HTTPS en of het HTTPS certificaat geldig is.

Pro-tip: als je een bestaande website hebt waar je HTTPS nog niet gebruikt, raden we je aan om als onderdeel van het website migratie proces naar HTTPS te migreren.

Lees verder over HTTPS

Beperk het gebruik van JavaScript

Een groot deel van SEO richt zich op het zo makkelijk mogelijk te maken voor zoekmachines om onze content op de juiste manier te crawlen en te indexeren. Wanneer je bij het bouwen van een website een Javascript framework gebruikt en erop vertrouwt dat het renderen aan de andere kant gebeurt, leidt dat tot het tegenovergestelde.

Terwijl zoekmachines tegenwoordig webpagina’s kunnen renderen, is het niet best practice om hier dan maar op te vertrouwen. Het leidt ertoe dat jouw content langzaam gecrawld en geïndexeerd wordt. Zorg, in plaats hiervan, dat je zoekmachines plain HTML voorlegt. En als je echt een JavaScript framework wilt gebruiken, zorg er dan voor dat je server-side rendering of een pre-rendering oplossing zoals prerender.io gebruikt.

De achterliggende redenering is als volgt:

  • Zoekmachines hebben beperkte resources om pagina’s te renderen. Het renderen van een pagina kan makkelijk meer dan twintig keer de resources kosten dan het crawlen van een reguliere HTML pagina, dus wijzen zoekmachines maar een klein deel van hun resources aan deze taak toe. Dit leidt ertoe dat het dagen, misschien zelfs weken duurt voordat jouw content geïndexeerd is.
  • Content dat niet geïndexeerd is heeft geen ranking. Voordat jouw content geïndexeerd is, krijg je geen enkel verkeer van zoekmachines.

SEO terzijde, client-side rendering leidt ook tot een langere Time to Interactive (TTI). Dit betekent dat bezoekers langer moeten wachten voordat ze met de pagina kunnen communiceren.

Lees meer over JavaScript

Pagina laadtijd

Onderzoek heeft aangetoond dat bezoekers snel ladende pagina’s op prijs stellen. Het verlaagt het bounce percentage en het verhoogt het conversie percentage. Amazon kwam erachter dat hun inkomsten 1% omhoog gingen voor elke vermindering van 100ms in de laadtijden. Snel ladende pagina’s helpen bovendien jouw SEO. Vooral wanneer je de competitie wilt aangaan op de eerste pagina van Google. Daar maakt snelheid echt een verschil.

Er zijn honderden kleine verbeteringen die je kunt doorvoeren op jouw website en webserver om een betere pagina laadtijd te krijgen, maar hier zijn de meest gebruikelijke best practices die je in overweging moet nemen.

  • Gebruik een Content Delivery Network
  • Beperk JavaScript en CSS
  • Optimaliseer afbeeldingen
  • Verminder de Server response tijd < 500ms
  • Gebruik browser caching en file compression

Lees meer over pagina snelheid

Dirk Ceuppens
Dirk Ceuppens

Bij elke front-end ontwikkeling valt het me op dat er gekozen wordt voor snelheid van ontwikkeling eerder dan voor snelheid van de site. Voor het design wordt vaak gekozen voor kant en klare templates en/of wordt er gebruik gemaakt van zware libraries zoals Bootstrap of Foundation. Voor individuele elementen worden dan nog vaak code gekopieerd van andere bronnen, met nieuwe dependencies. Eindresultaat is een site die er weliswaar blits uitziet maar tal van CSS en JS files oproept die maar nauwelijks worden gebruikt. Het kost meer tijd – maar vaak kan het zelfde design worden bereikt met vanilla JS & één custom CSS file. Tip: als je een specifieke functionaliteit maar op enkele pagina’s gebruikt laadt de bijbehorende js & css files ook alleen maar op die pagina’s.

Beelden zijn één van de gemakkelijkste elementen om je laadtijd te verbeteren. Nagenoeg elke site die ik check heeft tientallen beelden zwaarder dan 200 KB, vaak met uitschieters tot 2 MB. Responsive images (waarbij je verschillende beeldformaten gebruikt afhankelijk van schermgrootte) worden nauwelijks gebruikt, net zoals nieuwere beeldformaten zoals WebP. Het loont de moeite om te investeren in tools zoals Imgix of Cloudinary die beelden automatisch optimaliseren.

Hiërarchie van headings

Headings H1-H6 worden gebruikt om hiërarchie en duidelijkheid aan jouw webpagina te geven. Wanneer headings op de juiste wijze worden gebruikt, kunnen bezoekers snel jouw pagina’s scannen omdat het zoekmachines helpt de structuur en het onderwerp van de content te begrijpen.

Een pagina begint met een H1 heading.
Een pagina begint met een H1 heading.

Een H1 heading op een pagina moet het hoofdonderwerp van de pagina uitdrukken. Om deze reden moet je niet een H1 heading om een logo plaatsen en moet je maar één H1 heading per pagina gebruiken.

Lees meer over headings

Robots.txt

Het robots.txt bestand bevat de regels voor crawlers. Je gebruikt het om crawlers te vertellen tot welke secties zij geen toegang hebben en om ze hints te geven hoe ze jouw content efficiënt kunnen ontdekken door aan de locatie van de XML sitemap te refereren.

Het volgende is belangrijk wanneer je met robots.txt te doen hebt:

  • Verschillende zoekmachines interpreteren robots.txt op verschillende manieren.
  • Wees voorzichtig en pas geen Disallow toe op bestanden die nodig zijn voor het renderen van pagina’s. Dit verhindert zoekmachines jouw pagina’s te renderen, en het zou jouw SEO prestatie kunnen schaden.
  • En tenslotte: robots.txt is een erg krachtige tool. Wees er voorzichtig mee, want het kan makkelijk jouw hele website ontoegankelijk maken voor zoekmachines. Daarom is het belangrijk om jouw robots.txt bestand te monitoren.

Lees meer over robots.txt

Check of de robots.txt correct is ingesteld

Doe een snelle check om er zeker van te zijn dat jouw robots.txt er niet voor zorgt dat zoekmachines problemen hebben essentiële content te bereiken. En blijf deze ook monitoren - dit is de meest voorkomende SEO fail

Gelieve een geldige domeinnaam (www.voorbeeld.nl) op te geven.

XML sitemaps

XML sitemaps zijn een efficiënte manier waarop je zoekmachines kunt vertellen over de content die je op jouw website hebt. Daarom spelen ze een belangrijke rol bij het snel laten crawlen van jouw content nadat het gepubliceerd of bijgewerkt is.

Best practices voor XML sitemaps:

  • Houd de XML-sitemap bijgewerkt met de inhoud van jouw website.
  • Zorg ervoor dat het opgeschoond is: alleen indexeerbare pagina’s mogen worden opgenomen.
  • Verwijs naar de XML Sitemap in jouw robots.txt bestand.
  • Neem niet meer dan 50.000 URLs op in een enkele XML Sitemap.
  • Zorg ervoor dat de (ongecomprimeerde) bestandsgrootte niet meer dan 50MB is.
  • Wees niet geobsedeerd met de lastmod, priority en changefreq eigenschappen.

Houd er rekening mee dat er speciale XML sitemaps voor afbeeldingen en nieuwsartikelen zijn.

Lees meer over XML sitemaps

Informatie Architectuur

Informatie Architectuur is de kunst en wetenschap van het ontwerpen van een structuur zodat je content van jouw website kunt presenteren. Het draait om het definiëren van welke content je hebt, en hoe je die toegankelijk maakt. Informatie architectuur is in essentie het snijvlak van User Experience en SEO. Iedereen profiteert van een goede informatie architectuur, dus dit is een belangrijke fase wanneer een website gebouwd wordt.

In deze sectie gaan we verder in op de SEO vereisten voor de Informatie Architectuur wanneer het gaat om web development. Een deel hiervan bestaat uit het definiëren van de URL structuur, en hoe het zich gedraagt onder bepaalde omstandigheden.

Herman Maes
Herman Maes

Kies welke strijd je aangaat. Zoek uit wat voor type website je gaat ontwikkelen, en welke eigenschappen daar vanuit SEO oogpunt bijhoren.

Is het een website met focus op lokale vindbaarheid? Zorg er dan voor dat je tijd investeert in local SEO (bijv. door nabijgelegen steden, dorpen en regio’s te noemen). Dit is een van de meest vergeten zaken wanneer het lokale websites betreft.

Is het een webshop? Zorg dan dat je zoekwoorden met koop en vergelijk intentie in je content opneemt.

Is het een content gedreven website? Onderzoek dan of er content gaps in de content van jouw concurrenten zit.

URL structuur

URLs moeten beschrijvend, leesbaar en kort zijn. Welke structuur je ook kiest, zorg ervoor dat het consistent gebruikt wordt op je hele website.

Vermijd bovendien zo veel mogelijk het gebruik van parameters in URLs. Ze laten niet echt aan bezoekers zien wat ze kunnen verwachten op een pagina, en ze kunnen crawl issues veroorzaken.

De website moet ondersteuning hebben voor het definiëren van een template dat de URL-structuur bepaalt.

Om in overweging te nemen:

  • Gebruik je subdirectories in jouw URLs of niet?
  • Gebruik je een trailing slash (slash aan het einde van elke URL) of niet?
  • Je zult, indien nodig, de URL template handmatig moeten kunnen overschrijven.

Lees meer over URL structuur

Filters, varianten, en meerdere categorieën

Als een website filters bevat, beschrijf dan of ze een effect zullen hebben op de URL structuur, en of de resulterende URLs toegankelijk en indexeerbaar moeten zijn voor zoekmachines of niet.

Doe hetzelfde voor paginavarianten.

Voorbeeld: je gaat een nieuwe eCommerce website bouwen voor de verkoop van schoenen. Elke schoen is beschikbaar in verschillende kleuren en maten, wat makkelijk leidt tot tientallen productvarianten. Welke pagina’s wil je toegankelijk en indexeerbaar laten zijn, en welke niet?

En hoe zit het met blog artikelen die zich in meerdere categorieën bevinden? Of producten? Er zijn misschien goede redenen om dit te doen vanuit een gebruikersstandpunt, maar vanuit een SEO standpunt, kan het echt een probleem vormen.

Wij raden aan dat je voor jouw artikelen en producten een hoofdcategorie gebruikt die kan worden geïndexeerd. Andere categorieën waarin het artikel of product zich bevindt moeten dan niet-indexeerbaar zijn, zodat dubbele content wordt voorkomen.

Voorbeeld
Een blog artikel bevindt zich in categorieën A, B en C, wat tot de volgende URLs leidt:

  1. https://example.com/blog/a/example-article
  2. https://example.com/blog/b/example-article
  3. https://example.com/blog/c/example-article

Categorie A is de hoofdcategorie, dus dit artikel is indexeerbaar op https://example.com/blog/a/example-article.

https://example.com/blog/b/example-article en https://example.com/blog/c/example-article moeten een canonical URL hebben naar de hoofd-URL.

Lees verder over

Smart templates die je tijd besparen

Vanuit een SEO perspectief is het belangrijk dat je templates voor title tag, meta description, en headings kunt definiëren. Ze helpen je consistent te optimaliseren, terwijl ze je ook een hoop werk besparen.

Je moet deze templates kunnen definiëren op website niveau, maar ook voor categorie pagina’s en voor alle pagina’s in een bepaalde categorie. Specificiteit wint, dus het meest specifieke template voor een pagina moet worden gebruikt.

Voorbeeld #1

Type Element Template
Website Title $pageName - HappyShoes

Je hebt een pagina genaamd “Privacy Policy,” dus de title wordt: “Privacy Policy - HappyShoes.”

Voorbeeld #2

Type Element Template
Website Title $pageName - HappyShoes
Pages in Category “adidas” Title $pageName - Buy adidas shoes

Je hebt een pagina genaamd “adidas Ultra Boost size 44”, dus de title wordt: “adidas Ultra Boost size 44 - Buy adidas shoes”.

Handmatig overschrijven van smart defaults

Op een pagina niveau zul je deze templates moeten kunnen overschrijven met handmatig gedefinieerde templates.

Op deze manier kun je snel een default title tag template definieren voor al jouw blog artikelen. Of voor alle pagina’s omtrent een bepaalde service.

Lees verder:

Crawling & Indexering

Alle vereisten die beschreven worden in deze sectie zijn er op gericht om het crawl- en indexeringsproces van een zoekmachines zo soepel mogelijk te laten verlopen. Je wilt dat zoekmachines snel nieuwe of vernieuwde content kunnen vinden. En wanneer ze jouw content crawlen, wil je dat ze het zo snel mogelijk beschrijven.

Robots directives

Robots directives laat je kiezen hoe crawlers jouw pagina’s moeten behandelen. De meest bekende directives zijn de noindex en nofollow directives. Je kunt deze robots directives definiëren door middel van de meta tag in <head> sectie van een pagina, maar je kunt het ook doen middels de X-Robots-Tag in de HTTP header.

Robots directives moeten standaard indexering toestaan, en dus geen nofollow directive bevatten.

Ook hier wil je de robots directives op drie niveau’s instellen:

  • website niveau
  • categorie/segment niveau
  • pagina niveau

Lees meer over robots directives

Canonical URLs

Canonical URLs geven signalen aan zoekmachines welke van de identieke of sterk op elkaar lijkende pagina’s zij moeten indexeren. Als je bijvoorbeeld 3 bijna identieke pagina’s hebt —A, B, en C— en je wilt dat pagina A geïndexeerd, dan laat je B en C met een canonical link naar A verwijzen.

Canonical URLs moeten standaard zelfverwijzend zijn—dit vertelt aan zoekmachines zijn dat dit de juiste versie is die geïndexeerd moeten worden.

Wanneer het om canonicals gaat, definieer ze dan alleen op pagina niveau.

Best practices omtrent canonical URLs:

  • Gebruik absolute URLs, inclusief domein en protocol.
  • Definieer maar één canonical URL per pagina.
  • Definieer de canonical URL in de <head> section van de pagina of in de HTTP header.
  • Verwijs naar een indexeerbare pagina.

Lees meer over URLs

Relaties

De vereisten die beschreven worden in deze sectie leggen allemaal content relaties uit aan zoekmachines.

Paginering: link rel next/prev attributes

Zorg op een gepagineerde reeks pagina’s ervoor dat je de link rel="next" en rel="prev" link attributen gebruikt. Dit helpt zoekmachines om de samenhangen in de reeks pagina’s te begrijpen, en hoe ze ze het beste kunnen behandelen.

Een voorbeeld van een gepagineerde reeks pagina’s is een overzichtspagina van een blog met 10 gepagineerde pagina’s, die elke 10 blog artikelen tonen. Of een product categorie pagina die het productaanbod verdeeld heeft over 20 gepagineerde pagina’s.

Best practices omtrent link rel="next" en rel="prev" link attributen:

  • Alle pagina’s in de reeks moeten een zelfverwijzende canonical URL bevatten
  • Zorg ervoor dat de reeks niet onderbroken is
  • Vermijd zelfverwijzende redirects
  • Gebruik absolute URLs
  • Gebruik niet een noindex met gepagineerde pagina’s
  • Gebruik niet een nofollow voor links naar gepagineerde pagina’s
  • Neem geen gepagineerde pagina’s op in de XML sitemap

Lees meer over paginering

Hreflang attribute

Gebruik op een website die in meerdere talen en/of regio’s beschikbaar is het hreflang attribuut. Hethreflang attribuut wordt gebruikt om aan te geven in welke taal jouw content geschreven is en voor geografische regio jouw content bedoeld is. Je kunt het hreflang attribuut definiëren door het op te nemen in de <head> sectie, of door een HTTP header te gebruiken.

Stel dat je een engelse, nederlandse, en een franse versie van een website hebt. Je kunt dan het hreflang attribuut gebruiken om zoekmachines naar vertaalde versies van jouw pagina’s te verwijzen. De engelse versie van de pagina bevat dan het volgende in de <head> sectie:

<link rel="canonical" href="https://www.example.com/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/" />
<link rel="alternate" hreflang="nl" href="https://www.example.nl/" />
<link rel="alternate" hreflang="fr" href="https://www.example.fr/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Best practices omtrenthreflang attributen:

  • Verwijs naar de pagina en naar de vertaalde varianten.
  • Zorg ervoor dat je wederkerendehreflang attribute references.
  • Definieer de juiste taal en regio combinaties.
  • Stel altijd hreflang="x-default"in.
  • Hethreflang attribuut en de canonical URL moeten overeenkomen.
  • Gebruik absolute URLs bij het definiëren van hethreflang attribuut.
  • Gebruik één methode om hethreflang attribuut te implementeren.

Lees verder over hreflang

Structured data

Door middel van structured data, kun je extra informatie geven over jouw content. Je kunt bijvoorbeeld Schema.org voor zoekmachines gebruiken en Open Graph werkt op Facebook, LinkedIn, en Slack en Twitter Cards doen hetzelfde voor Twitter. Als je structured data gebruikt, neem je de controle over hoe jouw content wordt getoond.

Schema.org

Contentking - Schema.org - JSON

Schema.org wordt vaak gebruikt om een interview van markup te voorzien en om te communiceren wie een artikel geschreven heeft of tot welke organisatie de website behoort. Of in het geval van een lokaal bedrijf, kun je Schema.org gebruiken om uit te leggen wat voor bedrijf het is en wat de openingstijden zijn. Er bestaan vele mogelijkheden, dus zorg ervoor dat jouw website de definitie van Schema.org eigenschappen ondersteunt. De markup moet worden toegevoegd aan HTML.

Er zijn meerdere manieren waarop je Schema kunt definiëren, maar de meest populaire (en de voorkeur van Google) is het JSON-LD format.

Je zult ze moeten kunnen definiëren op de volgende niveau’s:

  • het website niveau (e.g. voor het definiëren van Organization)
  • het pagina niveau (e.g. voor het definiëren van Reviews)

Lees meer over Schema

Open Graph markup

Facebook Open Graph geillustreerd

Er zijn vier vereiste Open Graph eigenschappen die je moet kunnen definiëren:

  1. og:url
  2. og:title
  3. og:description
  4. og:image

Er zijn ook twee aanbevolen eigenschappen; gebruik deze om nog meer context voor de content te geven:

  1. og:type
  2. og:locale

Je zult ze moeten kunnen definiëren op de volgende niveau’s:

  • het Website niveau (e.g. voor het definiëren van een standaard afbeelding)
  • het Categorie/Segment niveau (e.g. voor het definiëren van een standaard afbeelding voor alle blog artikelen)
  • het Pagina niveau (e.g. voor het definiëren van Reviews)

Lees meer over Open Graph

Twitter Card markup

Twitter Cards geillustreerd

Hoewel Twitter Cards vergelijkbaar zijn met Open Graph zijn er vier verschillende types Twitter Cards:

  1. Summary Card
  2. Summary Card with Large Image
  3. App Card
  4. Player Card

Dit zijn de vereiste Twitter Card eigenschappen:

  • twitter:card
  • twitter:title

Maar we raden je ten zeerste aan om ook de drie volgende eigenschappen te definiëren zodat je meer context voor de content geeft:

  • twitter:site
  • twitter:description
  • twitter:image

Lees meer over Twitter Cards

Media optimization

Media zoals afbeeldingen en PDF files kunnen een hoop verkeer opleveren, en daarom is het essentieel dat je ze kunt optimaliseren.

Hoewel er verschillende factoren zijn die bepalen of een afbeelding al dan niet een hoge ranking krijgt, moet de website de definitie van eenalt attribuut en een title tag attribuut voor elke afbeelding ondersteunen. Wanneer je media upload, zorg er bovendien voor dat het URL pad logisch is.

WordPress’ standaard URL pad bevat bijvoorbeeld het jaar en de maand en dit leidt tot zeer lange URLs. Dit geeft mensen ook het verkeerde idee dat jouw media verouderd is wanneer het beschikbaar is op https://example.com/wp-content/uploads/uploads/2017/06/.

Zorg ervoor dat je een XML sitemap voor de afbeelding gebruikt zodat zoekmachines snel en makkelijk jouw afbeeldingen kunnen vinden.

Lees meer over media optimization

Zoals we hebben beschreven in de sectie over Informatie Architectuur sectie, is het voor SEO erg belangrijk hoe jouw content toegankelijk is voor bezoekers.

Het is daarom essentieel dat je jouw navigatie kunt beheren. Er zijn verschillende types navigatie, zoals bijvoorbeeld:

  • Main navigation
  • Sidebar navigation
  • Footer navigation

Zorg ervoor dat je deze kunt beheren voor de website, en in het bijzonder voor bepaalde delen van de website. Neem bijvoorbeeld een eCommerce website waar schoenen, broeken en truien verkocht worden. In de schoenen sectie wil je een sidebar en footer definiëren die alleen links bevatten naar jouw belangrijkste productpagina’s en sub-categorie pagina’s over schoenen.

Conclusie

Als een nieuwe website SEO proof moet zijn bij de lancering, moet het aan de juiste specificaties voldoen. Gebruik dit artikel in jouw voordeel, en klik voor meer informatie vooral op de links naar de diepgaande artikelen over de onderwerpen die genoemd worden.

En als je als je éénmaal aan alle SEO vereisten voor de nieuwe website voldaan hebt, bereid je dan voor op de volgende stap: een toekomstige website migratie.

ContentKing Academy Content Team
Steven van Vessum
Steven van Vessum

Steven is onze Chief Customer Officer. Hij zorgt ervoor dat onze klanten tevreden zijn én blijven. Daarnaast is hij gek op alles wat met SEO en content marketing te maken heeft!

Vojtěch Zach
Vojtěch Zach

Vojtěch is ContentKing’s Customer Support & Localization Manager. He is the one who will answer your questions when you reach out to us. He is a studied translator, so apart from making our users happy, he also loves to take on our localization challenges.

Lorena Torsani
Lorena Torsani

Lorena is ContentKing’s Marketing Specialist. She’s a creative thinker, who is highly enthusiastic about engaging with customers, running exciting campaigns and bringing forth some fresh ideas.

Probeer 14 dagen gratis

Binnen 20 seconden aan de slag

Gelieve een geldige domeinnaam (www.voorbeeld.nl) op te geven.
  • Geen credit card nodig
  • Geen installatie nodig
  • Geen verplichtingen