Un portal regional pasa de 800 a 12.000 anuncios en dieciocho meses. El SEO está progresando, al igual que el tráfico: modesto en volumen general, pero cada visitante inicia una búsqueda. Un filtro “tres habitaciones, balcón, menos de 350.000 euros, radio de cinco kilómetros” genera una consulta intensa, diez fotos en carga diferida, un mosaico de mapa y, a veces, una alerta por correo electrónico. El compartido todavía contiene el HTML. MySQL pasa de 200 ms a ocho segundos en búsquedas populares.
Un portal inmobiliario no es un blog inmobiliario. La restricción no es “mantener 10.000 páginas vistas por día”, sino mantener 10.000 combinaciones de filtros en un catálogo vivo, con medios pesados y referencias que indexen cada archivo.
Tres pilares: indexación, medios, búsqueda
| Pilar | Síntoma si el tamaño es deficiente | Palanca |
|---|---|---|
| Indexación básica | Búsquedas > 2 s, procesador MySQL al 100% | Índices compuestos, EXPLICAR, lectura de réplicas |
| Fotos | Disco lleno, TTFB alto | Objeto + CDN, miniaturas, compresión |
| Buscar | Tiempos de espera en tarjeta/filtros | Elasticsearch, Meilisearch, PostGIS |
En un portal inmobiliario, la página de listado es una consulta analítica disfrazada de página web. Trátelo como tal.
Indexación: la consulta que mata antes que el tráfico
Los errores clásicos siguen apareciendo: falta el índice en (ciudad, tipo, precio, área) a pesar de que la interfaz filtra exactamente eso; ORDER BY fecha DESC sin un índice de cobertura que provoca una clasificación en 50.000 líneas; agencia se une → anuncio → foto sin límite en el número de imágenes cargadas.
Antes de publicarlo, ejecute EXPLAIN en las diez consultas más frecuentes (panel de análisis o registro de consultas lentas). Cree un índice compuesto alineado con el orden de los filtros de interfaz. Imponer paginación (de 24 a 48 anuncios como máximo por página). Búsquedas “principales” en caché de Redis (apartamento de dos habitaciones en el centro de la ciudad, etc.) con un TTL corto.
Para obtener más información, consulte Falta índice MySQL: reconocer la consulta que hace caer el sitio.
##Fotos: el peso invisible del catálogo
Un anuncio “estándar”: doce fotos × 1,5 MB = 18 MB almacenados. Multiplique por 12.000 anuncios: las matemáticas del disco explican las migraciones de emergencia.
La arquitectura saludable implica una carga en el almacenamiento de objetos (Scaleway, OVH, Infomaniak Object Storage), un procesamiento asíncrono que produce miniaturas WebP de 800 px, una CDN con caché larga en los medios y corta en el HTML del formulario (el precio cambia), y una purga inmediata cuando se elimina un anuncio.
Nunca publique el 4000x3000 original en la lista. La experiencia de la página de Google y su impulso se lo agradecerán.
Búsqueda por facetas y geográfica: cuando MySQL por sí solo es suficiente
| Volumen de anuncios | Buscar | Recomendación |
|---|---|---|
| <2000 | Texto + ciudad | MySQL o PostgreSQL bien indexados |
| 2.000 – 20.000 | Multifiltros + tarjeta | PostGIS o Meilisearch |
| > 20.000 | Facetas + agregaciones | Elasticsearch u OpenSearch dedicados |
El mapa interactivo multiplica las solicitudes: cada zoom corresponde a una nueva zona geográfica. Oculte mosaicos y clústeres en el lado del servidor o calcule previamente por zona.
Hosting: más allá de “WordPress con caché”
El frente escaparate de la agencia se puede compartir. El motor de publicidad personalizado, Elasticsearch, 500 GB de fotos y las importaciones masivas de CSV requieren un VPS o una nube con almacenamiento de objetos, trabajadores en cola y réplicas de lectura si la búsqueda domina.
Una importación nocturna de anuncios desde un CRM puede saturar la E/S mientras los usuarios realizan búsquedas por la mañana. Aísle las importaciones en una cola de Celery o en un servidor de trabajo dedicado.
La cumbre: el SEO genera tráfico que su base de datos no planeaba recibir
El marketing quiere "más anuncios indexados". Las operaciones deben responder "cada modelo de búsqueda tiene un plan de rendimiento"; de lo contrario, ganará tráfico y perderá conversión.
Decide y avanza sin puntos ciegos
Primero enumere las diez búsquedas más lentas a través del registro de consultas lentas. Subcontrate los medios antes de alcanzar los 100 GB o el 80 % del disco. Pruebe una importación masiva combinada con tráfico de búsqueda simultáneo en la puesta en escena. Habilite CDN y compresión en todas las miniaturas de la lista. Establezca un umbral de inclinación: si la latencia en el percentil 95 de las búsquedas supera los 1,5 segundos, cambie a un motor dedicado o lea una réplica.
Compare hosts con almacenamiento de objetos a través del directorio y el comparador. Para la replicación de lectura, consulte Replicación de bases de datos: ¿disponibilidad o lectura más rápida?.
Preguntas frecuentes
¿Por qué un portal inmobiliario se satura tan rápido al compartirse?
Cada búsqueda multicriterio puede escanear miles de filas sin un índice adecuado; cada hoja carga de diez a veinte fotografías. El procesador, la memoria y la E/S del disco aumentan juntos, no solo el tráfico de páginas vistas.
¿Es necesario Elasticsearch para un portal inmobiliario?
De unos pocos miles de anuncios activos con búsqueda por facetas, un motor dedicado o PostgreSQL con PostGIS es más estable que las consultas LIKE no indexadas en MySQL.
¿Dónde alojar las fotos de los anuncios?
Almacenamiento de objetos y CDN; Miniaturas WebP o AVIF al importar, nunca el original en la lista.
¿Cómo dimensionar la búsqueda geográfica?
Índice espacial, caché de consultas frecuentes, paginación estricta: no es necesario realizar un análisis completo de un mapa.
Un portal inmobiliario se reproduce en índices SQL y archivos de fotografías, no en la cantidad de núcleos que se muestran en la hoja de host.