Een RealWorks WordPress-plugin is meestal de beste keuze als je snel actueel woningaanbod op een bestaande WordPress-site wilt zetten. Maatwerk past beter wanneer de website ook verkochte woningen moet bewaren, aanvragen gecontroleerd naar het CRM moet sturen of afwijkende zoek-, SEO- en beheerlogica nodig heeft. De juiste keuze hangt dus niet af van welk systeem meer functies noemt, maar van welke processen niet mogen uitvallen.
Onze stelling is eenvoudig: kies een plugin voor een standaard aanbodstroom, maar kies maatwerk zodra je website onderdeel wordt van het verkoopproces van je kantoor. Een woningkaart tonen is een afgebakende taak. Een woningdetail bewaren na verkoop, iedere aanvraag terugvindbaar opslaan en dynamische pagina’s in de sitemap krijgen, vraagt om keuzes die verder gaan dan de basisimport.
Wat doet een RealWorks WordPress-plugin?
Een RealWorks WordPress-plugin haalt woninggegevens uit RealWorks CRM en zet deze in WordPress. Nieuwe objecten, foto’s, kenmerken en statuswijzigingen hoeven daardoor niet nog een keer handmatig in de website te worden ingevoerd.
Allround Web biedt hiervoor een kant-en-klare plugin. Op 2 september 2026 vermeldde de openbare productpagina ondersteuning voor Wonen en BOG, onbeperkte objecten, RealWorks-webhooks, WordPress custom post types, shortcodes en template-overrides. Ook noemt de pagina compatibiliteit met Elementor, Divi, WPML en Polylang.
Dat is een duidelijk voordeel. Heb je al een WordPress-site en wil je vooral het actuele aanbod koppelen, dan kan een bestaand product veel ontwikkelwerk voorkomen. Je krijgt een bekende installatie, documentatie en een jaar updates en ondersteuning. Volgens dezelfde openbare pagina stond de hoofdplugin op dat moment op €199 per jaar en begon de inbouwservice bij €245 eenmalig. Deze bedragen zijn een momentopname en kunnen veranderen.
Wanneer wint een bestaande plugin?
Een plugin wint vooral als je wensen dicht bij de standaard blijven:
- Woningen uit RealWorks moeten automatisch in WordPress verschijnen.
- Status, prijs, kenmerken en foto’s moeten worden bijgewerkt.
- Het aanbod moet via shortcodes of templates in een bestaande site passen.
- Je gebruikt een gangbare pagebuilder of een meertaligheidsplugin.
- Je wilt vooraf een duidelijk product en een beperkte implementatie.
In die situatie is maatwerk niet automatisch beter. Zelf een complete synchronisatielaag bouwen kost tijd en brengt onderhoud met zich mee. De RealWorks API kan veranderen, WordPress krijgt updates en webhooks kunnen opnieuw getest moeten worden. Een leverancier die hetzelfde product bij meerdere makelaars onderhoudt, kan dat werk over meer klanten verdelen.
Voor een kantoor met Wonen én BOG heeft Allround Web nog een concreet voordeel: die ondersteuning staat publiek beschreven. Ook nieuwbouw en agrarisch en landelijk vastgoed worden als uitbreidingen genoemd. Wie meerdere vastgoedcategorieën direct wil koppelen, hoeft daardoor niet ieder datamodel vanaf nul te laten bouwen.
Wanneer wordt maatwerk logisch?
Maatwerk wordt logisch zodra het gewenste gedrag niet eindigt bij “object importeren en tonen”. Bij een makelaarssite die wij bouwden, kwamen vier eisen naar voren die samen de architectuur bepaalden.
1. Geen RealWorks-aanroep tijdens ieder websitebezoek
We bouwden een lokale RealWorks-spiegel in WordPress. Een geplande synchronisatie bewaart de volledige objectdata lokaal. Daarna hebben we de tijdelijke opslag gewist en een woningpagina geladen. Dat leverde nul nieuwe API-aanroepen op tijdens het paginabezoek. Hoe je een trage mobiele pagina daarna opspoort, lees je in waarom WordPress op mobiel trager is dan op desktop.
Het voordeel is niet alleen snelheid. Als RealWorks tijdelijk niet reageert, kan de website nog steeds bestaand aanbod tonen. Ook blijft objectdata beschikbaar nadat een woning uit de actieve feed verdwijnt.
2. Verkochte woningpagina’s niet zomaar verwijderen
In onze eerste opzet verdween de WordPress-woningpost uit publicatie zodra RealWorks het object niet meer als actief aanleverde. Een bestaande link naar die woning gaf daardoor een 404-pagina.
We hebben dit opgelost met een archieffallback. De verkochte woning blijft op dezelfde detail-URL beschikbaar met HTTP-status 200, krijgt duidelijk de status verkocht en toont geen prijs. Een onbekende URL blijft wel een echte 404. Zo blijft het verkooptrackrecord zichtbaar zonder een verkochte woning als actueel aanbod te presenteren. Hoe dit bij die makelaar uitpakte, lees je in de volledige case.
3. Dynamische woningpagina’s in de sitemap krijgen
Niet iedere woningdetailpagina bestaat als gewone WordPress-post. Daardoor neemt de standaard WordPress-sitemap zulke pagina’s niet vanzelf mee.
Voor het verkochte archief bouwden we daarom een eigen sitemap-provider. Die voegde 115 verkochte woning-URL’s toe die daarvoor volledig ontbraken. Dit bewijst niet dat iedere URL automatisch goed gaat ranken. Het zorgt er wel voor dat zoekmachines de juiste lijst met bestaande pagina’s kunnen ontdekken.
4. Een aanvraag bewaren voordat mail of CRM wordt aangeroepen
Een formulier mag niet afhankelijk zijn van één geslaagde e-mail of API-reactie. Daarom wordt iedere aanvraag eerst lokaal in WordPress opgeslagen. Pas daarna gaan de notificatiemail en de RealWorks-push lopen.
De push start dertig seconden na de aanvraag. Bij een fout probeert het systeem het ieder kwartier opnieuw, tot maximaal tien pogingen. De volledige route van formulier naar WordPress-aanvraag, RealWorks CRM en inbox is getest. Tijdens die test bleek zelfs dat de echte RealWorks-response relatieId terugstuurde waar vooraf entityId werd verwacht. Zonder lokale opslag had zo’n afwijking eruit kunnen zien als een verloren aanvraag.
Plugin en maatwerk naast elkaar
| Onderdeel | Bestaande plugin | Maatwerk koppeling |
|---|---|---|
| Starttijd | Meestal sneller | Eerst analyse en bouw nodig |
| Vooraf afgebakend product | Sterk | Afhankelijk van scope |
| Gangbare WordPress-tools | Vaak al ondersteund | Per tool testen en bouwen |
| Afwijkende formulieren en CRM-routes | Afhankelijk van uitbreidingen | Volledig in te richten |
| Verkocht-archief en bestaande URL’s | Controleren wat het product doet | Gedrag zelf bepalen |
| Sitemap voor niet-standaard pagina’s | Controleren in demo en documentatie | Eigen provider mogelijk |
| Onderhoud | Gedeeld product en leverancier | Eigen beheerafspraken nodig |
| Ontwerp- en procesvrijheid | Binnen beschikbare hooks en templates | Groot, maar kost meer werk |
De vergelijking is dus niet “goedkoop tegenover goed” of “standaard tegenover professioneel”. Een bestaande plugin kan technisch precies voldoende zijn. Maatwerk kan juist onnodig worden als je alleen woningen wilt importeren. De verkeerde keuze ontstaat wanneer je pas na de installatie ontdekt dat een essentieel proces buiten de standaard valt.
Zo maak je de keuze vóór je koopt
Schrijf eerst de processen op die bij een storing of statuswijziging goed moeten blijven gaan:
- Wat gebeurt er met een woningdetailpagina nadat het object is verkocht?
- Blijven bestaande woninglinks werken?
- Staan alle openbare woningpagina’s werkelijk in de XML-sitemap?
- Wordt een formulier eerst lokaal opgeslagen?
- Wat ziet de makelaar als een CRM-push mislukt?
- Wordt een mislukte push automatisch opnieuw geprobeerd?
- Kan het aanbod blijven laden als RealWorks tijdelijk niet bereikbaar is?
- Ondersteunt de oplossing Wonen, BOG, nieuwbouw of andere benodigde categorieën?
- Wie test de koppeling opnieuw na updates van WordPress of RealWorks?
Laat deze punten in een demo zien. Een functielijst zegt dat een archief bestaat. Een test met een verkochte woning laat zien wat er echt met de URL, status, sitemap en data gebeurt.
Veelgestelde vragen
Is een RealWorks WordPress-plugin voldoende voor iedere makelaar?
Nee. Voor automatisch woningaanbod kan een plugin ruim voldoende zijn. Heb je eigen CRM-routes, afwijkende filters, een blijvend verkocht-archief of specifieke foutafhandeling nodig, controleer dan eerst of het product dat gedrag ondersteunt.
Is maatwerk altijd sneller dan een plugin?
Nee. Snelheid hangt af van caching, afbeeldingsformaten, synchronisatie en wat er tijdens een paginabezoek gebeurt. Zowel een plugin als maatwerk kan snel zijn, maar je moet meten of de bezoekerspagina voor iedere woning een externe API nodig heeft.
Kan een verkochte woning beter worden verwijderd?
Niet automatisch. Verwijder de woning uit het actieve aanbod, maar bepaal apart wat er met de bestaande detail-URL gebeurt. Een bruikbaar archief kan het trackrecord bewaren, terwijl lege of onvolledige detailpagina’s juist moeten worden voorkomen.
Waar moet ik op letten bij een offerte voor een RealWorks-koppeling?
Vraag niet alleen welke gegevens worden geïmporteerd. Vraag ook naar opslag, retries, logging, verkochte woningen, sitemaps, redirects, updates en verantwoordelijkheid bij storingen. Laat kritieke routes vóór livegang testen.
Welke route past bij jouw makelaarssite?
Bekijk eerst hoe we koppelingen met software als RealWorks aanpakken en wat we in onze projecten laten zien. Wil je weten of een bestaande RealWorks-plugin voldoende is of dat jouw processen maatwerk nodig hebben, plan dan een rustige intake. We brengen eerst de uitzonderingen in kaart en adviseren daarna pas welke route logisch is.