Een regionaal portaal gaat in achttien maanden van 800 naar 12.000 advertenties. SEO vordert, net als het verkeer: bescheiden in totaalvolume, maar elke bezoeker start een zoekopdracht. Een filter ‘drie kamers, balkon, minder dan € 350.000, straal vijf kilometer’ levert een zware zoekopdracht op, tien foto’s in lazyloading, een kaarttegel en soms een e-mailalert. Het gedeelde bevat nog steeds de HTML. MySQL gaat van 200 ms naar acht seconden bij populaire zoekopdrachten.
Een vastgoedportaal is geen vastgoedblog. De beperking is niet “het behouden van 10.000 pageviews per dag” – het is het behouden van 10.000 filtercombinaties in een levende catalogus, met zware media en verwijzingen die elk bestand indexeren.
Drie pijlers: indexering, media, zoeken
| Pijler | Symptoom als het formaat niet goed is | Hendel |
|---|---|---|
| Basisindexering | Zoekopdrachten > 2 s, MySQL-processor op 100% | Samengestelde indexen, UITLEG, replica lezen |
| Foto's | Schijf vol, TTFB hoog | Object + CDN, miniaturen, compressie |
| Zoeken | Time-outs op kaart / filters | Elasticsearch, Meilisearch, PostGIS |
Op een vastgoedportaal is de lijstpagina een analytische zoekopdracht, vermomd als een webpagina. Behandel het als zodanig.
Indexering: de zoekopdracht die het verkeer doodt
De klassieke fouten blijven terugkomen: ontbrekende index op (stad, type, prijs, gebied) ook al filtert de interface precies daarop; ORDER BY date DESC zonder een dekkingsindex die een sortering op 50.000 regels veroorzaakt; bureau sluit zich aan bij → advertentie → foto zonder limiet op het aantal geladen afbeeldingen.
Voordat u live gaat, voert u EXPLAIN uit op de tien meest voorkomende query's (analysedashboard of log met langzame query's). Maak een samengestelde index die is afgestemd op de volgorde van de interfacefilters. Paginering opleggen (maximaal 24 tot 48 advertenties per pagina). Redis cache “top” zoekopdrachten (tweekamerappartement in het centrum, enz.) met een korte TTL.
Voor meer informatie, zie Ontbrekende MySQL-index: herken de zoekopdracht die de site neerhaalt.
Foto's: het onzichtbare gewicht van de catalogus
Een “standaard” advertentie: twaalf foto’s × 1,5 MB = 18 MB opgeslagen. Vermenigvuldig met 12.000 advertenties: schijfwiskunde verklaart noodmigraties.
De gezonde architectuur omvat een upload naar objectopslag (Scaleway, OVH, Infomaniak Object Storage), asynchrone verwerking die 800 px WebP-thumbnails produceert, een CDN met lange cache op de media en kort op de HTML van het formulier (de prijs verandert), en een onmiddellijke opschoning wanneer een advertentie wordt verwijderd.
Serveer nooit de originele 4000x3000 in de lijst. De Google Page Experience en uw rit zullen u dankbaar zijn.
Gefacetteerd en geografisch zoeken: wanneer MySQL alleen voldoende is
| Advertentievolume | Zoeken | Aanbeveling |
|---|---|---|
| <2000 | Tekst + stad | MySQL of PostgreSQL goed geïndexeerd |
| 2.000 – 20.000 | Multifilters + kaart | PostGIS of Meilisearch |
| > 20.000 | Facetten + aggregaties | Toegewijd Elasticsearch of OpenSearch |
De interactieve kaart vermenigvuldigt de verzoeken: elke zoom komt overeen met een nieuw geografisch gebied. Verberg tegels en clusters aan de serverzijde of bereken vooraf per zone.
Hosting: verder dan “WordPress met cache”
De voorkant van het bureau kan worden gedeeld. Aangepaste advertentie-engine, Elasticsearch, 500 GB aan foto's en enorme CSV-importen vereisen een VPS of cloud met objectopslag, werknemers in de wachtrij en leesreplica als de zoekopdracht domineert.
Een nachtelijke import van advertenties uit een CRM kan de I/O verzadigen terwijl gebruikers 's ochtends zoeken. Isoleer importen in een Celery-wachtrij of speciale werkserver.
De top: SEO brengt verkeer dat uw database niet van plan was te ontvangen
Marketing wil “meer geïndexeerde advertenties”. Operaties moeten antwoorden: “elk zoekmodel heeft een prestatieplan” – anders genereert u verkeer terwijl u conversie verliest.
Beslis en ga vooruit zonder blinde vlek
Maak eerst een lijst van de tien langzaamste zoekopdrachten via het langzame querylogboek. Besteed de media uit voordat u 100 GB of 80% van de schijf bereikt. Test een enorme import gecombineerd met gelijktijdig zoekverkeer tijdens de staging. Schakel CDN en compressie in voor alle lijstminiaturen. Stel een kanteldrempel in: Als de latentie bij het 95e percentiel van de zoekopdrachten groter is dan 1,5 seconde, schakel dan over naar een speciale engine of leesreplica.
Vergelijk hosts met objectopslag via de overzicht en de vergelijker. Voor leesreplicatie raadpleegt u Databasereplicatie: beschikbaarheid of sneller lezen?.
Veelgestelde vragen
Waarom raakt een vastgoedportaal zo snel verzadigd als het wordt gedeeld?
Elke zoekopdracht op meerdere criteria kan duizenden rijen scannen zonder een geschikte index; op elk vel staan tien tot twintig foto's. Processor, geheugen en schijf-I/O gaan allemaal samen omhoog, niet alleen het paginaweergaveverkeer.
Is Elasticsearch noodzakelijk voor een vastgoedportaal?
Van een paar duizend actieve advertenties met gefacetteerde zoekopdrachten is een speciale engine of PostgreSQL met PostGIS stabieler dan niet-geïndexeerde LIKE-query's op MySQL.
Waar advertentiefoto's hosten?
Objectopslag en CDN; WebP- of AVIF-thumbnails bij importeren, nooit het origineel in de lijst.
Hoe kan ik geografisch zoeken aanpassen?
Ruimtelijke index, cache voor frequente zoekopdrachten, strikte paging – geen volledige scan voor een kaart.
Een vastgoedportaal wordt uitgespeeld in de SQL-indexen en fotobestanden – niet in het aantal kernen dat op het hostblad wordt weergegeven.