Categorie:AlleAISEOMarketingDesignCodeWordpressWoocommerceHTML/CSS

Oude blogartikelen updaten: waarom verversen vaak meer oplevert dan nieuw schrijven

Verfblikken en verfroller voor een frisgeschilderde groene muur

De reflex van veel ondernemers die aan contentmarketing doen: er moet wéér een nieuw artikel bij. Maar wie al een tijdje blogt, heeft een archief vol artikelen die ooit goed scoorden en langzaam wegzakken — verouderde jaartallen, achterhaalde schermafbeeldingen, gebroken links, adviezen die niet meer kloppen. Juist daar zit de snelste SEO-winst. Een bestaand artikel opfrissen kost een fractie van de tijd van een nieuw artikel, en het heeft een voorsprong die nieuwe content niet heeft: het staat al in de index, heeft al links en heeft al bewezen dat het kán ranken.

Waarom Google verse content beloont

Google wil zoekers het beste antwoord van nú geven. Voor veel onderwerpen — prijzen, wetgeving, tools, trends — veroudert het beste antwoord vanzelf. Een artikel “Wat kost een webshop in 2023?” verliest terrein aan concurrenten met actuele cijfers, hoe goed het ooit ook was. Bovendien ziet Google aan gedrag dat een artikel veroudert: zoekers klikken, zien een oud jaartal, klikken terug en kiezen een ander resultaat. Een grondige update draait dat om. In de praktijk zie je geüpdatete artikelen vaak binnen enkele weken stijgen — veel sneller dan een nieuw artikel, dat maandenlang vertrouwen moet opbouwen.

Welke artikelen pak je als eerste aan?

Niet alles verdient een opknapbeurt. Open Google Search Console en zoek artikelen die aan dit profiel voldoen: ze krijgen nog steeds vertoningen, maar de kliks of gemiddelde positie dalen gestaag — of ze blijven hangen op positie 5 tot 15, nét buiten de topposities. Dat zijn artikelen waarvan Google de relevantie al erkent; een update is dan vaak het duwtje naar de top drie. Artikelen die nooit bezoekers hebben getrokken én over een onderwerp gaan dat niemand zoekt, laat je links liggen — of je verwijdert ze en verwijst ze door naar een sterker artikel over hetzelfde onderwerp.

Zo pak je een content-update aan

  • Actualiseer feiten, cijfers en jaartallen — ook in de titel als daar een jaartal in staat.
  • Herlees met de zoekvraag in gedachten: welke vragen stelt iemand die dit zoekt vandaag, en beantwoordt het artikel die nog? Vul aan wat mist, schrap wat niemand meer boeit.
  • Vervang verouderde schermafbeeldingen en voorbeelden en repareer gebroken links.
  • Voeg interne links toe van en naar artikelen die je sindsdien hebt geschreven — je archief is gegroeid, je linkstructuur meestal niet.
  • Behoud de URL. De opgebouwde waarde zit aan dat adres vast; pas hooguit titel en inhoud aan. Zet wel de publicatie- of wijzigingsdatum bij, zodat zoekers (en Google) de versheid zien.

Maak er een gewoonte van

Content updaten werkt het best als vast ritme, niet als eenmalige inhaalslag. Een praktisch schema voor een MKB-blog: reserveer één contentmoment per maand voor onderhoud in plaats van nieuwbouw, en loop elk kwartaal je tien belangrijkste artikelen na. Zo bouw je een archief op dat in zijn geheel actueel blijft — en dat is precies het soort website dat Google structureel hoger zet dan een archief dat alleen maar groeit.

Conclusie

Je bestaande artikelen zijn geen afgesloten hoofdstukken maar bezit dat onderhoud verdient. Kies via Search Console de artikelen die wegzakken of nét buiten de top ranken, actualiseer feiten, antwoorden en links, en houd de URL intact. Wie updaten net zo serieus neemt als schrijven, haalt meer uit minder werk.

Geplaatst in de categorie: SEO

Paginatitels en meta descriptions schrijven die kliks opleveren

Boekenkasten vol boeken in een boekwinkel

Voordat iemand je website ooit ziet, ziet hij eerst twee regels tekst in Google: je paginatitel en je meta description. Die paar woorden zijn je etalage in de zoekresultaten — ze bepalen of de zoeker op jouw resultaat klikt of op dat van de concurrent erboven. Toch worden ze op veel websites automatisch gegenereerd of achteloos ingevuld. Zonde, want een betere titel schrijven kost vijf minuten en kan de doorklikratio van een pagina zomaar verdubbelen. Meer kliks uit dezelfde positie: goedkoper wordt SEO niet.

Wat zijn de paginatitel en meta description precies?

De paginatitel (title tag) is de blauwe klikbare regel in het zoekresultaat; de meta description is het grijze tekstje eronder. Beide stel je per pagina in — in WordPress doe je dat eenvoudig via een SEO-plugin zoals Yoast, in het vak onder de editor. Belangrijk om te weten: de titel telt mee als rankingfactor (Google leest eruit waar de pagina over gaat), de meta description niet. Maar de description beïnvloedt wél of mensen klikken, en een resultaat waar veel op geklikt wordt, doet het op termijn beter. Ze hebben dus allebei een baan: de titel moet ranken én verleiden, de description hoeft alleen te verleiden.

Zo schrijf je een sterke paginatitel

  • Zet het zoekwoord vooraan. “WordPress onderhoud uitbesteden | HakHak” werkt beter dan “HakHak | Alles over het uitbesteden van onderhoud”. Zoekers scannen van links naar rechts en Google kort lange titels af.
  • Blijf onder de circa 60 tekens. Langer wordt afgekapt met een beletselteken — precies op het moment dat het interessant werd.
  • Maak een belofte, geen omschrijving. “Wat kost een website in 2026? Eerlijk overzicht” verslaat “Prijzen websites”. Getallen, jaartallen en woorden als “stappenplan” of “checklist” trekken de blik.
  • Eén unieke titel per pagina. Twintig pagina’s met dezelfde titel betekent dat Google zelf maar wat kiest — en dat je pagina’s met elkaar concurreren.

Zo schrijf je een meta description die klikt

Je hebt ongeveer 155 tekens. Gebruik ze als een mini-advertentie: benoem het probleem van de zoeker, vertel wat hij op de pagina vindt en sluit af met een reden om nú te klikken. Schrijf actief (“Bekijk de tarieven”, “Lees het stappenplan”) en verwerk het zoekwoord één keer — Google maakt het vet in het resultaat, wat extra opvalt. Vermijd loze kreten als “welkom op onze website”. En weet: Google toont soms een eigen fragment uit de pagina in plaats van jouw description, vooral bij zoekopdrachten waar jouw tekst niet op aansluit. Dat is geen fout van jou; een goede description wordt in de meeste gevallen gewoon getoond.

Waar begin je op een bestaande website?

Niet bij pagina één, maar bij de pagina’s waar winst zit. Open Google Search Console en sorteer je pagina’s op vertoningen: pagina’s met veel vertoningen maar een lage doorklikratio (CTR) zijn je goudmijn. Die worden al vaak getoond — er klikt alleen niemand. Herschrijf daar titel en description, wacht twee tot vier weken en vergelijk de CTR. Zo werk je de lijst van boven naar beneden af en zie je per pagina wat het oplevert.

Conclusie

Je paginatitel en meta description zijn de eerste — en soms enige — kennismaking met je bedrijf in Google. Zet het zoekwoord vooraan in een titel onder de 60 tekens, schrijf een description als mini-advertentie en begin bij pagina’s met veel vertoningen en weinig kliks. Kleine moeite, direct meetbaar resultaat.

Geplaatst in de categorie: SEO

Git en versiebeheer: waarom de code van je website in een repository hoort

Vertakkende boomtak tegen een blauwe lucht als metafoor voor Git-branches

Vraag een timmerman naar zijn gereedschap en hij noemt zijn zaag. Vraag een goede webdeveloper hetzelfde en het antwoord is: Git. Versiebeheer is het fundament onder professioneel ontwikkelwerk — en toch draait een verrassend groot deel van de zakelijke websites zonder. Wijzigingen gaan dan rechtstreeks de live server op, de vorige versie bestaat alleen nog in back-ups en niemand weet meer wie wat wanneer heeft aangepast. Als website-eigenaar hoef je Git niet te kunnen bedienen, maar je wilt wél begrijpen waarom het ertoe doet — al is het maar om er bij je webbouwer naar te vragen.

Wat is versiebeheer?

Versiebeheer is een systeem dat elke wijziging aan de code van je website vastlegt: wat er veranderde, wie het deed, wanneer en waarom. Git is daarvoor de wereldstandaard. De complete geschiedenis staat in een zogeheten repository, vaak gehost op een platform als GitHub of GitLab. Vergelijk het met de versiegeschiedenis van een Google-document, maar dan strenger: elke wijziging wordt als bewust “commit”-moment vastgelegd met een omschrijving erbij, en je kunt naar elk eerder punt in de geschiedenis terug — van vijf minuten tot vijf jaar geleden.

Wat levert dat concreet op voor jouw website?

  • Elke wijziging is terug te draaien. Gaat een aanpassing mis, dan staat de vorige werkende versie één commando verderop — geen paniek-restore van een complete back-up nodig.
  • Meerdere mensen, geen chaos. Developers werken in eigen “branches” aan losse features en voegen die gecontroleerd samen. Niemand overschrijft elkaars werk.
  • Een logboek van je website. “Sinds wanneer doet het formulier raar?” is opzoekbaar: de historie toont exact welke wijziging wanneer live ging.
  • Gecontroleerd live zetten. Vanuit Git kan een wijziging automatisch naar staging en productie worden uitgerold (deployment) — geen bestanden meer via FTP over de live site heen slepen.
  • Onafhankelijkheid. De code van je site staat compleet en gedocumenteerd op een neutrale plek. Wissel je van bureau, dan draag je een repository over in plaats van een zip-bestand en losse eindjes.

Hoe zit dat bij WordPress?

Bij een WordPress-site hoort niet álles in Git thuis. De vuistregel: code wél, data en bijlagen niet. In de repository horen het (child-)thema, eigen plugins en configuratie — alles wat ontwikkeld wordt. De database (berichten, bestellingen, instellingen) en de uploads-map (afbeeldingen) horen in je back-upstrategie, niet in versiebeheer; die veranderen immers door gebruik, niet door ontwikkeling. Deze scheiding is precies waarom een professionele partij zowel Git áls back-ups regelt: het zijn twee verschillende vangnetten voor twee verschillende soorten wijzigingen.

De vraag die je je webbouwer mag stellen

“Staat de code van mijn website in versiebeheer, en kan ik bij de repository?” is een volstrekt redelijke vraag — vergelijkbaar met vragen of een aannemer een bouwtekening bijhoudt. Het antwoord zegt veel over de werkwijze: wie met Git, staging en gecontroleerde deployments werkt, levert aantoonbaar reproduceerbaar werk. Vraag ook of jij (of een toekomstige partij) toegang tot de repository kunt krijgen; het is tenslotte de code van jóuw website. Een professionele partij regelt dat zonder aarzelen.

Conclusie

Versiebeheer met Git maakt van websitecode een gedocumenteerd, terugdraaibaar en overdraagbaar geheel in plaats van een verzameling bestanden op een server. Voor jou als eigenaar betekent het minder risico bij wijzigingen, een opzoekbare historie en onafhankelijkheid van één partij. Je hoeft er zelf niets voor te leren — alleen de juiste vraag te stellen aan wie aan je site werkt.

Geplaatst in de categorie: Code

Variabele producten in WooCommerce: maten, kleuren en varianten goed instellen

Kledingrek met kleding in verschillende kleuren en maten in een winkel

Een T-shirt in vijf maten en drie kleuren is in je hoofd één product, maar voor je webshop zijn het vijftien combinaties — elk met een eigen voorraad, soms een eigen prijs en een eigen foto. WooCommerce lost dat op met variabele producten. Goed ingesteld kiest de klant soepel zijn maat en kleur en klopt je voorraad altijd; slecht ingesteld wordt het een kluwen van dubbele producten, misgrijpen en een trage shop. Het verschil zit in een paar principes die je één keer goed moet leren.

Attributen en variaties: het verschil begrijpen

De opbouw kent twee lagen die vaak verward worden. Attributen zijn de eigenschappen en hun mogelijke waarden: het attribuut “Maat” met waarden S tot en met XL, het attribuut “Kleur” met zwart, wit en blauw. Variaties zijn de concrete combinaties die je verkoopt: “M / zwart” is een variatie, met een eigen prijs, voorraad, artikelnummer en foto. De juiste volgorde: maak eerst de attributen aan als globale attributen (onder Producten → Attributen), niet per product. Globale attributen kun je hergebruiken over je hele assortiment, en alleen daarmee werken filters op categoriepagina’s (“toon alles in maat M”). Daarna koppel je ze aan het product, vink je “gebruikt voor variaties” aan en laat je WooCommerce alle combinaties genereren.

De instellingen die het verschil maken

  • Geef elke variatie een eigen prijs — ook als die gelijk is. Variaties zonder prijs zijn niet bestelbaar, de klassieke oorzaak van “het product is niet te kiezen”.
  • Beheer voorraad per variatie. Zet voorraadbeheer op variatieniveau aan, zodat maat M uitverkocht kan zijn terwijl L gewoon leverbaar blijft.
  • Koppel foto’s aan variaties. Kiest de klant “blauw”, laat dan het blauwe shirt zien. Het is een klein detail dat het vertrouwen — en de conversie — merkbaar verhoogt.
  • Geef elke variatie een eigen artikelnummer (SKU). Onmisbaar zodra je koppelt met voorraadbeheer, boekhouding of Google Shopping.
  • Toon kleuren als stalen, geen dropdown. Kleurvlakjes en maatknoppen kiezen prettiger dan een uitklaplijstje; moderne thema’s en lichte plugins regelen dit.

Houd het beheersbaar

WooCommerce genereert combinaties multiplicatief: drie attributen met elk zes waarden zijn al 216 variaties — per product. Dat vertraagt je beheer én je shop. Drie vuistregels houden het gezond. Eén: maak alleen variaties van eigenschappen die écht een andere levering betekenen; “materiaal: katoen” dat voor alle varianten geldt, is gewoon een attribuut zonder variatie, handig voor filters. Twee: verkoop je een combinatie niet, verwijder die variatie dan in plaats van hem op nul voorraad te laten staan. Drie: bij honderden variaties per product loont bulkbewerking via de ingebouwde bulk-acties of een CSV-import — met de hand 200 prijzen aanpassen is vragen om fouten.

Als de standaard niet meer volstaat

Soms groeit de behoefte voorbij wat variaties aankunnen: een offerte-achtige samenstelling (een deur met afmetingen op maat), prijsopbouw per optie (“graveren + 5 euro”) of afhankelijkheden tussen keuzes (“bij kleur wit is XL niet leverbaar”). Daarvoor bestaan product-addon-plugins en maatwerkoplossingen die bovenop het variatiesysteem werken. De grens is praktisch: zodra je merkt dat je het aantal variaties kunstmatig laag houdt of prijslogica in de omschrijving uitlegt, is het tijd voor een slimmere productconfiguratie.

Conclusie

Variabele producten zijn de juiste manier om maten, kleuren en uitvoeringen te verkopen — mits je de opbouw respecteert: globale attributen als fundament, variaties alleen voor echte verschillen, elke variatie met eigen prijs, voorraad, SKU en foto. Houd het aantal combinaties beheersbaar en schakel op naar addons of maatwerk zodra je productlogica complexer wordt dan het variatiesysteem aankan. Dan blijft kiezen voor de klant simpel — en het beheer voor jou ook.