Categorie:AlleAISEOMarketingDesignCodeWordpressWoocommerceHTML/CSS

Spam via je contactformulier stoppen: zo houd je je inbox schoon

Rij kleurrijke brievenbussen langs de weg

Elke ondernemer met een contactformulier kent het: tussen de echte aanvragen door druppelen — of stromen — de spamberichten binnen. Aanbiedingen voor SEO-diensten, cryptische links, formulieren vol wartaal. Vervelend voor je inbox, maar ook riskant: tussen vijftig spamberichten mis je die ene echte aanvraag zomaar. Het goede nieuws: formulierspam is voor het overgrote deel te stoppen, zonder je bezoekers te hinderen.

Waar komt formulierspam vandaan?

Vrijwel alle formulierspam komt van bots: programma’s die het internet afstruinen naar formulieren en die automatisch invullen. Een klein deel komt van menselijke spammers, vaak uit lagelonenlanden, die captcha’s gewoon oplossen. Dat onderscheid is belangrijk, want het bepaalt welke maatregel werkt: bots stop je met techniek, menselijke spam alleen met filtering.

De eerste verdedigingslinie: honeypot en tijdscontrole

De vriendelijkste anti-spammaatregelen zijn onzichtbaar voor echte bezoekers:

  • Honeypot: een verborgen veld dat mensen niet zien maar bots wél invullen. Is het veld gevuld, dan wordt het bericht geweigerd. Vrijwel elke formulierenplugin heeft dit ingebouwd — zet het aan.
  • Tijdscontrole: een mens doet minstens enkele seconden over een formulier; een bot vult het in milliseconden in. Formulieren die te snel worden verzonden, worden geweigerd.

Deze twee samen stoppen het merendeel van de botspam en kosten je bezoekers helemaal niets — geen puzzels, geen verkeersborden aanklikken.

Captcha’s: effectief, maar met een prijs

Blijft er spam doorkomen, dan is een captcha de volgende stap. De bekendste is Google reCAPTCHA, maar die heeft nadelen: het laadt een fors script mee op elke pagina (slecht voor je laadtijd), het deelt bezoekersgegevens met Google (een aandachtspunt onder de AVG) en de puzzels frustreren echte bezoekers. Privacyvriendelijkere alternatieven zoals hCaptcha of het onzichtbare Cloudflare Turnstile doen hetzelfde werk met minder bijwerkingen. Vuistregel: begin met de onzichtbare maatregelen en zet pas een captcha in als het echt nodig is — elke drempel in een formulier kost conversie.

Inhoudsfilters voor de hardnekkige gevallen

Tegen menselijke spammers en slimme bots helpt filtering op inhoud: berichten met bepaalde trefwoorden, cyrillisch schrift of meer dan een paar links automatisch blokkeren of in quarantaine zetten. Diensten als Akismet (ook voor formulieren) en de ingebouwde filters van serieuze formulierenplugins doen dit degelijk. Blokkeer eventueel ook verzendingen uit landen waar je aantoonbaar nooit klanten uit haalt — maar wees daar terughoudend mee als je internationaal zaken doet.

Wat je beter níét doet

Het e-mailadres van het formulier vervangen door een afbeelding, het formulier weghalen, of drie captcha’s stapelen: het zijn oplossingen die vooral je échte klanten raken. Hetzelfde geldt voor het verplicht maken van tig velden om spammers te ontmoedigen — elke extra verplichte vraag kost aanvragen van echte bezoekers. Het doel is niet nul spam; het doel is dat elke echte aanvraag moeiteloos binnenkomt en spam de uitzondering is.

Conclusie

Formulierspam bestrijd je in lagen: eerst de onzichtbare maatregelen (honeypot en tijdscontrole), dan een privacyvriendelijke captcha als het nodig blijft, en inhoudsfilters voor de restjes. Kies altijd de oplossing die je echte bezoekers het minst hindert — een schoon postvak is mooi, maar een gemiste klant is duurder dan tien spamberichten.

Back-ups van je website: zo regel je het goed (en waarom één back-up geen back-up is)

Harde schijven voor het opslaan van website-back-ups

Een mislukte update, een hack, een vergissing in de database of een hostingpartij met een storing: er zijn tientallen manieren waarop een website van het ene op het andere moment kapot kan gaan. Er is maar één echte verzekering tegen al die scenario’s tegelijk: een goede back-up. Maar “we hebben back-ups” blijkt in de praktijk vaak schijnzekerheid. In dit artikel lees je hoe je het wél goed regelt.

Wat moet er in een back-up zitten?

Een complete WordPress-back-up bestaat uit twee delen: de bestanden (thema’s, plugins, geüploade afbeeldingen en documenten) en de database (alle pagina’s, berichten, instellingen en bestellingen). Alleen bestanden of alleen de database is een halve back-up — je hebt beide nodig om een site volledig te herstellen. Vooral bij webshops is de database het kloppende hart: daar staan je orders en klanten in.

De 3-2-1-regel

De gouden standaard voor back-ups is de 3-2-1-regel: drie kopieën van je gegevens, op twee verschillende soorten opslag, waarvan één op een andere locatie. Voor een website betekent dat vooral: bewaar back-ups niet alleen op je eigen server. Gaat de server stuk of wordt hij gehackt, dan ben je anders je site én je back-ups in één klap kwijt. Laat back-ups automatisch wegschrijven naar externe opslag zoals Google Drive, Dropbox of een S3-opslag.

Hoe vaak moet je back-uppen?

De vraag is eigenlijk: hoeveel werk kun je je veroorloven te verliezen? Voor een website die wekelijks verandert, volstaat een dagelijkse back-up. Voor een webshop met dagelijkse bestellingen wil je de database vaker veiligstellen — elk uur of zelfs continu — want elke verloren order is een boze klant. Bewaar daarnaast meerdere generaties (bijvoorbeeld 30 dagen): een hack of fout wordt soms pas na weken ontdekt, en dan moet je terug kunnen naar een versie van vóór het probleem.

Vertrouw niet blind op je hostingpartij

Veel hostingpakketten bevatten back-ups, en dat is een prima eerste laag. Maar controleer wat het precies inhoudt: hoe vaak, hoe lang bewaard, en — cruciaal — kun je zelf herstellen of moet je een ticket indienen en wachten? Bovendien staan die back-ups bij dezelfde partij als je site zelf. Een eigen back-uproutine ernaast, met een plugin die naar externe opslag schrijft, kost weinig en maakt je onafhankelijk.

Een back-up die je nooit getest hebt, bestaat niet

De pijnlijkste ontdekking die je kunt doen is een back-up die niet terug te zetten blijkt — corrupt, incompleet of in een formaat waar je niets mee kunt. Test daarom periodiek een herstel, bijvoorbeeld op een testomgeving. Dan weet je niet alleen dat de back-up werkt, maar ook hoe lang herstel duurt en welke stappen erbij komen kijken. Juist op het moment van een echte calamiteit wil je dat niet voor het eerst uitzoeken.

Vergeet de momenten die er het meest toe doen

Automatische back-ups draaien op vaste tijden, maar de riskantste momenten kies je zelf: vlak voor een grote update, een nieuwe plugin of een wijziging aan je thema. Maak op die momenten altijd even een handmatige back-up. Eén klik vooraf bespaart uren herstelwerk achteraf.

Conclusie

Een goede back-upstrategie is automatisch, compleet (bestanden én database), extern opgeslagen, met meerdere generaties en — bovenal — af en toe getest. Het is onzichtbaar werk waar je hopelijk nooit iets aan hebt. Maar op de dag dat het misgaat, is het verschil tussen “even terugzetten” en “alles kwijt” precies dit lijstje.

Een meertalige website maken: waar moet je op letten?

Boekenplank met woordenboeken en Engelstalige opbergdozen

Klanten over de grens, internationale medewerkers of een tweetalige doelgroep in eigen land: er zijn genoeg redenen om je website in meerdere talen aan te bieden. Maar een meertalige website is meer dan je teksten door een vertaalmachine halen. In dit artikel lees je hoe je meertaligheid in WordPress goed aanpakt — technisch, organisatorisch en voor je vindbaarheid.

Eerst de strategische vraag: welke talen, en waarom?

Elke taal die je toevoegt, verdubbelt een deel van je onderhoud: nieuwe pagina’s, blogartikelen en productteksten moeten voortaan in elke taal worden bijgehouden. Begin daarom niet met vijf talen “voor het geval dat”, maar met de taal waar aantoonbaar vraag is — kijk in je statistieken waar je bezoekers vandaan komen. Een halfvertaalde website met verouderde Engelse teksten doet meer kwaad dan goed.

Meertaligheid in WordPress: de opties

WordPress is standaard eentalig; meertaligheid voeg je toe met een plugin. De twee bekendste:

  • WPML is de meest complete oplossing: vertaalbeheer per pagina, ondersteuning voor WooCommerce, koppelingen met vertaaldiensten en automatische vertaling als startpunt. Betaald, en op zware sites merkbaar in de prestaties als hij niet goed is ingericht.
  • Polylang is lichter en in de basis gratis: prima voor websites die gewoon twee of drie talen naast elkaar nodig hebben zonder complexe workflows.

Voor grote internationale opzetten bestaat nog een derde route: een multisite met per taal een eigen site. Dat geeft maximale vrijheid per land, maar ook het meeste beheer. Voor de meeste MKB-websites is een plugin de juiste keuze.

Machinevertaling: prima startpunt, geen eindstation

Automatische vertaling is de laatste jaren indrukwekkend goed geworden en prima als eerste versie. Maar juist de pagina’s waar het om draait — je homepage, dienstenpagina’s, productteksten — verdienen een menselijke redactieslag. Vertaalfouten in commerciële teksten kosten direct vertrouwen, en nuances als aanspreekvorm (u of jij, formeel of informeel) bepaalt een machine niet voor je. Vuistregel: machine vertaalt, mens redigeert, en commerciële kernpagina’s schrijf je het liefst opnieuw voor die markt.

De SEO-kant: hreflang en URL-structuur

Voor zoekmachines zijn twee dingen essentieel. Ten eerste een duidelijke URL-structuur per taal: submappen (jouwdomein.nl/en/) zijn voor de meeste sites de praktische keuze. Ten tweede hreflang-tags: onzichtbare labels die Google vertellen welke pagina de Engelse variant van welke Nederlandse pagina is. Zonder hreflang kan Google de verkeerde taalversie tonen of vertaalde pagina’s als duplicaten zien. Goede meertaligheidsplugins regelen dit automatisch — mits elke pagina netjes aan zijn vertaling gekoppeld is.

Vergeet de details niet

Een echt goede meertalige site vertaalt méér dan de pagina’s: menu’s, knoppen, formulieren, foutmeldingen, e-mailbevestigingen, de cookiebanner en bij webshops ook valuta, betaalmethodes en verzendinformatie. Juist die details bepalen of een buitenlandse bezoeker zich serieus genomen voelt — of halverwege het contactformulier ineens in het Nederlands wordt aangesproken.

Conclusie

Een meertalige website begint met een bewuste keuze voor talen waar echt vraag naar is, krijgt technisch vorm met een plugin als WPML of Polylang, en valt of staat met twee dingen: menselijke redactie van de vertalingen en een correcte hreflang-inrichting voor Google. Doe je dat goed, dan opent elke taal letterlijk een nieuwe markt voor je bedrijf.

Belanden je e-mails in spam? SPF, DKIM en DMARC uitgelegd

Rij kleurrijke brievenbussen langs een weg

Je webshop verstuurt keurig een orderbevestiging, maar de klant vindt hem terug in de spammap — of ontvangt hem helemaal niet. Sinds Google en Microsoft hun regels voor afzenders hebben aangescherpt, is dit een van de meest voorkomende problemen bij websites en webshops. De oplossing zit in drie technische afspraken: SPF, DKIM en DMARC. Klinkt droog, maar het principe is goed te begrijpen.

Waarom komt e-mail in spam terecht?

E-mail is van oudsher makkelijk te vervalsen: iedereen kan technisch gezien een mail versturen “namens” jouwdomein.nl. Ontvangende mailservers zijn daarom streng geworden: kun je niet bewijzen dat een e-mail écht namens jouw domein verstuurd mag worden, dan belandt hij in spam of wordt hij geweigerd. Juist e-mails vanaf je website — contactformulieren, orderbevestigingen, wachtwoord-resets — versturen vaak via een route die zonder configuratie niet te verifiëren is.

De drie pijlers: SPF, DKIM en DMARC

SPF: wie mag er namens jouw domein versturen?

SPF (Sender Policy Framework) is een DNS-record waarin je opsomt welke servers e-mail namens jouw domein mogen versturen: je mailprovider, je webserver, je nieuwsbriefdienst. Ontvangers controleren bij elke binnenkomende mail of de verzendende server op dat lijstje staat. Let op: je hebt precies één SPF-record, waarin alle diensten samenkomen — meerdere records naast elkaar maken je SPF ongeldig.

DKIM: een digitale handtekening

DKIM (DomainKeys Identified Mail) voegt aan elke uitgaande e-mail een cryptografische handtekening toe. De ontvangende server controleert die handtekening via een sleutel in jouw DNS. Klopt hij, dan staat vast dat de mail onderweg niet is aangepast en echt bij jouw domein hoort.

DMARC: het beleid dat alles samenbindt

DMARC vertelt ontvangers wat ze moeten doen met e-mail die de SPF- en DKIM-controle niet doorstaat: gewoon afleveren (none), in quarantaine zetten of weigeren. Google en Microsoft eisen inmiddels van vrijwel alle afzenders minimaal een DMARC-record. Begin met beleid “none” en rapportages, en schroef aan naar “quarantine” zodra je zeker weet dat al je legitieme mailstromen goed staan.

En je WordPress-website dan?

Standaard verstuurt WordPress e-mail rechtstreeks vanaf de webserver via PHP — precies het soort route dat bij ontvangers wantrouwen wekt. De betrouwbaarste oplossing is je website te laten versturen via SMTP met een geauthenticeerd e-mailaccount of een transactionele maildienst. Een SMTP-plugin regelt dat in een paar minuten. Controleer daarna of de verzendroute ook in je SPF-record staat en DKIM-ondertekening actief is.

Zo controleer je of het goed staat

Stuur een testmail naar een Gmail-adres en kijk via “Origineel weergeven” of SPF, DKIM en DMARC alle drie op “PASS” staan. Online tools als MXToolbox laten bovendien zien of je DNS-records geldig zijn. Doe deze check ook opnieuw wanneer je overstapt van mailprovider of een nieuwe dienst namens je domein laat mailen.

Conclusie

SPF, DKIM en DMARC vormen samen het bewijs dat jouw e-mail echt van jou komt. Zonder die drie records belandt zelfs volstrekt legitieme mail steeds vaker in spam. Het instellen is eenmalig werk van een uurtje — en het scheelt gemiste offertes, verdwenen orderbevestigingen en frustratie bij je klanten.