Un sitio inmobiliario genera cientos, a veces miles de URL relacionadas con anuncios, páginas de barrios, filtros de búsqueda y paginación. El sitemap XML determina qué páginas priorizarán los robots de Google durante el rastreo. En este tipo de sitio, no dominar este archivo equivale a dejar que Googlebot decida por sí solo qué explorar, con un riesgo directo de dilución del presupuesto de rastreo en páginas sin valor.
Presupuesto de rastreo y anuncios inmobiliarios: el verdadero problema técnico
Google asigna a cada sitio un volumen de rastreo limitado. En un portal inmobiliario, la mayoría de las URL son efímeras: un bien vendido desaparece del catálogo en pocas semanas, pero su URL sigue siendo accesible si no se hace nada. Si el sitemap continúa referenciando estas páginas expiradas, el rastreo se dispersa en anuncios muertos en lugar de concentrarse en los bienes activos.
El problema se agrava con las páginas de resultados de filtros. Cada combinación “3 habitaciones + terraza + Burdeos” puede generar una URL distinta. Multiplique por el número de criterios disponibles y obtendrá un volumen de páginas facetadas que supera con creces el número de anuncios reales. Estas URL inflan artificialmente el índice sin aportar contenido único.
Recomendamos incluir en el sitemap solo tres categorías de páginas: las fichas de bienes en curso de comercialización, las páginas de zonas geográficas duraderas (ciudad, barrio, distrito) y los contenidos editoriales. Todo lo demás, incluidos los anuncios expirados, debe ser excluido y tratado mediante una redirección o un código 410.
Para observar esta lógica aplicada a un caso concreto, el sitemap de yakaimmo.fr ilustra la estructuración de un archivo orientado hacia los contenidos activos de un portal inmobiliario.
Sitemap inmobiliario y ciclo de vida de los bienes: sincronizar el archivo con el flujo de anuncios
Un sitemap estático es incompatible con un catálogo inmobiliario dinámico. Los bienes entran y salen del stock de manera constante. El archivo debe reflejar este estado en tiempo real, o al menos diariamente.
La etiqueta <lastmod> cobra aquí todo su peso. Si no se actualiza cuando un anuncio cambia de precio o de estado, Google no percibe ninguna señal de frescura. En un sitio donde decenas de fichas evolucionan cada día, un lastmod fijo equivale a decirle al robot que nada se mueve.
Concretamente, la sincronización entre el CRM inmobiliario (o el flujo de datos de la red) y el sitemap debe seguir esta lógica:
- Un bien publicado añade automáticamente su URL al sitemap con la fecha del día en lastmod.
- Un bien vendido, retirado o expirado elimina su URL del sitemap en las 24 horas y devuelve un código HTTP 410 (Gone) o una redirección 301 hacia la página de la zona correspondiente.
- Una modificación de precio o de descripción actualiza el lastmod sin tocar la URL misma.
Esta mecánica evita enviar señales contradictorias a Googlebot: una URL presente en el sitemap pero que devuelve un 404 genera errores de cobertura en la Search Console y degrada la confianza global del dominio.
Diagnóstico cruzado: sitemap, logs del servidor y Crawl Stats
Enviar un sitemap limpio no es suficiente. También hay que verificar que Google realmente rastrea las páginas que le envías. Es aquí donde el cruce entre el sitemap y los logs del servidor se convierte en una etapa de diagnóstico técnico en sí misma.
El informe Crawl Stats de la Search Console indica el número de solicitudes diarias y el tiempo de respuesta promedio. Paralelamente, el análisis de los logs del servidor revela qué URL visita realmente Googlebot. En un sitio inmobiliario voluminoso, es frecuente que el robot gaste una parte significativa de su presupuesto en páginas de paginación o URL de filtros, mientras ignora fichas de bienes recién publicadas.
El diagnóstico consiste en comparar tres listas:
- Las URL presentes en el sitemap (lo que le pides a Google que explore).
- Las URL efectivamente rastreadas por Googlebot (lo que muestran los logs).
- Las URL indexadas (lo que confirma el informe de cobertura).
Si la diferencia entre el sitemap y las URL rastreadas supera un umbral razonable, esto señala un problema de arquitectura: enlaces internos insuficientes hacia las nuevas fichas, tiempo de respuesta del servidor demasiado alto o presencia de URL parásitas que captan el rastreo. Un sitemap bien construido no compensa una malla interna deficiente, pero permite medir con precisión dónde se encuentra la pérdida.
Renderizado JavaScript y sitemap: una restricción específica de los portales inmobiliarios
Muchas plataformas inmobiliarias se basan en frameworks de JavaScript (React, Vue, Angular) para mostrar las fichas de bienes y los resultados de búsqueda. Google puede renderizar el JavaScript, pero con un retraso y límites de recursos. El sitemap no resuelve este problema: enviar una URL renderizada únicamente en JS no garantiza su indexación.
Si el contenido principal de una ficha (dirección, precio, superficie, fotos) depende completamente del renderizado del lado del cliente, el robot puede rastrear la URL referenciada en el sitemap y no encontrar más que una cáscara vacía en el primer paso. La página se pondrá en cola para un segundo renderizado, sin garantía de tiempo.
Observamos que los sitios inmobiliarios que combinan un renderizado del servidor (SSR) para los elementos críticos de la ficha y un sitemap actualizado obtienen una cobertura de indexación significativamente superior a aquellos que solo confían en el sitemap para compensar un renderizado full-JS. El sitemap indica a dónde ir, pero no reemplaza la calidad técnica de lo que el robot encuentra al llegar.
Un sitemap inmobiliario eficaz se basa en tres pilares: la sincronización con el flujo de anuncios, la exclusión rigurosa de URL sin valor y la verificación regular mediante el cruce de logs/Crawl Stats. Sin este trabajo de mantenimiento, el archivo sigue siendo un inventario pasivo que no mejora ni la velocidad de indexación ni la visibilidad de los bienes en venta.