SEO técnico para sitios web inmobiliarios

Introducción

El problema técnico más común en una web inmobiliaria no es que las páginas posicionen mal. Es que nunca llegan a entrar en la carrera.

Publicas páginas de comunidad, el feed añade miles de propiedades, y meses después Search Console muestra un montón de URL paradas en Rastreada, actualmente sin indexar o Detectada, actualmente sin indexar. Nada está roto de una forma que nadie note. El tráfico simplemente no llega.

Los sitios IDX lo sufren más que la mayoría, por razones estructurales. Este artículo explica por qué, y qué merece la pena hacer de verdad.

⚡ Respuesta rápida — ¿por qué no se indexa mi web IDX? Normalmente por una de cuatro cosas: los buscadores no pueden descubrir la página, el presupuesto de rastreo se gasta en URL de filtro y de ordenación en vez de en páginas que importan, el contenido solo aparece después de ejecutarse el JavaScript, o la página es un casi duplicado de otra URL de tu propio sitio. Además, las fichas de propiedad son el contenido menos distintivo que tienes, así que indexarlas no las vuelve competitivas por sí solo.

Las cinco etapas, y dónde se paran los sitios

Una página tiene que sobrevivir a una secuencia antes siquiera de poder posicionar. Google la describe como rastreo, renderizado e indexación — y una web inmobiliaria puede fallar en cualquier punto.

Averiguar en qué etapa se detuvo una página es la mayor parte del diagnóstico. El informe de indexación de páginas de Search Console nombra la etapa; la herramienta de inspección de URL muestra qué renderizó Google realmente.

Rastreabilidad

robots.txt. Compruébalo primero, y compruébalo después de cualquier migración de plataforma. Bloquear un directorio que contiene tus páginas de comunidad es un error de cinco minutos que tarda meses en notarse.

Enlaces internos. Este es el mayor problema de descubrimiento en las webs inmobiliarias. Las páginas generadas en bloque — una por comunidad, una por edificio — a menudo no tienen nada que enlace a ellas. Si a una página solo se llega tecleando su URL, trátala como invisible.

Mapas del sitio. Un mapa del sitio ayuda al descubrimiento pero no compensa una página a la que nada enlaza. Google trata las páginas huérfanas como de baja prioridad estén o no en un mapa del sitio.

URL con parámetros. Aquí es donde muere el presupuesto de rastreo en los sitios IDX. Las combinaciones de filtros se multiplican: cinco filtros con un puñado de opciones cada uno producen miles de URL sobre el mismo inventario. Google es directo sobre el riesgo y advierte de que la implementación por defecto de la navegación por facetas genera «espacios de URL infinitos» que provocan sobrerrastreo y ralentizan el descubrimiento del contenido genuinamente nuevo.

La lectura práctica: cada petición gastada en ?sort=price&page=7 es una petición no gastada en la página de comunidad que escribiste la semana pasada.

Renderizado

Hay que jubilar dos afirmaciones obsoletas antes de poder decir aquí nada útil.

«Google no puede ejecutar JavaScript.» Sí puede. La documentación de Google es explícita: en cuanto los recursos lo permiten, «un Chromium sin interfaz renderiza la página y ejecuta el JavaScript».

«Entonces el renderizado da igual.» Sigue importando. El renderizado se pone en cola, y Google señala que una página «puede permanecer en esta cola unos segundos, pero puede tardar más». Google recomienda de todos modos el renderizado en servidor o el prerrenderizado, porque «hace que tu sitio sea más rápido para usuarios y rastreadores, y no todos los bots pueden ejecutar JavaScript» — algo que importa cada vez más a medida que los rastreadores de IA se vuelven una fuente real de visitas.

En inmobiliaria en concreto, el riesgo se concentra en tres sitios:

• Datos de la propiedad traídos del lado del cliente tras la carga. Si el precio, las habitaciones y la dirección llegan mediante una petición posterior, pueden no estar en lo que se indexa.
• Páginas de resultados construidas enteramente en el navegador. A menudo está bien dejarlas sin indexar de todos modos, pero hazlo a propósito.
• Enrutado de aplicación de página única. Google advierte de que el enrutado del lado del cliente hace impracticables los códigos de estado HTTP significativos, lo que produce soft 404. Las URL con fragmentos son peores: Google «por lo general no admite fragmentos de URL en el rastreo y la indexación».

La prueba es sencilla. Abre la inspección de URL, lanza una prueba en vivo y lee el HTML renderizado. Si los datos de tu propiedad no están ahí, tu posicionamiento tampoco.

Indexabilidad

noindex. Búscalo antes de teorizar sobre nada más. Sobrevive a migraciones y a entornos de pruebas con una persistencia notable.

Códigos de estado. Una propiedad retirada debe devolver 404 o 410, o redirigir a algo genuinamente equivalente. Lo que no debe hacer es devolver 200 con una plantilla vacía — un soft 404, que desperdicia rastreo y puede lastrar las señales de calidad.

Cadenas de redirección. Habituales tras un cambio de plataforma. Cada salto cuesta, y las cadenas largas a veces dejan de seguirse.

Páginas pobres y casi duplicadas. La verdadera restricción en los sitios IDX, y el tema de la sección siguiente.

El contenido duplicado en IDX, bien entendido

La versión folclórica — las propiedades del MLS son contenido duplicado, así que las páginas IDX no pueden posicionar — es demasiado tosca para actuar sobre ella, y lleva a la gente a poner en noindex cosas que debería conservar.

Se confunden dos problemas distintos.

Problema uno: las mismas propiedades aparecen en la web de cada participante. Cierto, y por eso las fichas rara vez posicionan en nada competitivo. Pero no hay penalización automática por ello. Las indicaciones de Google sobre URL duplicadas van de consolidar señales hacia una URL preferida, no de castigar. Las fichas siguen ganándose su sitio — convierten, sirven a los visitantes recurrentes, alimentan las búsquedas guardadas. Simplemente no son tu activo de posicionamiento.

Problema dos: tu propio sitio genera muchas URL sobre el mismo inventario. Este es el que controlas, y el que de verdad desperdicia rastreo.

Fíjate en lo que el diagrama no dice: canonicalizar cada filtro hacia la página de ciudad. Hazlo y borrarás /homes/toronto/condos — una página con demanda de búsqueda real — junto con ?sort=price.

La distinción que hay que sostener es entre una combinación de filtros que coincide con cómo busca la gente y una que solo reordena o estrecha. La primera merece una URL real, un título real y contenido real. La segunda no necesita existir como página indexable.

URL canónicas, usadas a conciencia

Una canónica le dice a Google qué URL preferirías que representara un contenido. Consolida las señales — los enlaces, en particular — en una sola dirección.

Dos cosas de ella importan en la práctica.

Es una preferencia, no una orden. Decide Google. Si tu canónica apunta a algo que no es sustancialmente la misma página, cuenta con que la ignore.

No es obligatoria. El propio texto de Google dice que «ninguna es obligatoria; es probable que tu sitio funcione perfectamente sin especificar una preferencia canónica». Un antídoto útil frente a la idea de que toda URL necesita una.

Dónde se gana el sueldo en una web inmobiliaria: cuando a la misma página se llega por varias direcciones — con y sin barra final, con parámetros de seguimiento, con un identificador de sesión. Apúntalas todas a la URL limpia.

Dónde no: como respuesta general a la navegación por facetas. Google es explícito en que, para eso, las canónicas y el nofollow son «por lo general menos eficaces a largo plazo» que el robots.txt o los filtros basados en fragmentos, aunque pueden reducir gradualmente el volumen de rastreo.

Mapas del sitio

Divídelos por grupo lógico en vez de entregar un único archivo enorme:

La razón es diagnóstica. Search Console informa de la cobertura por mapa del sitio, así que separarlos te dice qué grupo no se está indexando. Un archivo combinado solo te dice que algo va mal.

Para las propiedades, mantén el mapa del sitio a la par del feed. Un mapa del sitio que anuncia miles de URL que ahora dan 404 es una señal que no quieres enviar. Cuánto tiempo puede seguir mostrándose públicamente una propiedad vendida es otra cuestión, y la fija tu MLS — mira Cumplimiento de MLS e IDX.

Arquitectura del sitio y enlaces internos

La arquitectura que posiciona es una jerarquía, no un montón plano:

Inicio → mercado → ciudad → comunidad → propiedad

Cada nivel debe enlazar hacia el siguiente y de vuelta hacia arriba, para que existan caminos de rastreo sin mapa del sitio y para que la autoridad fluya hacia las páginas que te importan. Esa estructura se trata en SEO inmobiliario: la guía completa; técnicamente importan tres cosas.

Sin huérfanas. Si una página no está enlazada desde ningún sitio, no forma parte del sitio a efectos de rastreo.

Migas de pan. Dan a cada página una posición explícita en la jerarquía y un enlace de vuelta hacia arriba. Además producen marcado BreadcrumbList limpio de regalo.

Enlaces contextuales antes que bloques de enlaces. Un enlace dentro de una frase sobre el barrio lleva contexto. Treinta enlaces en un pie de página no llevan casi ninguno.

Las páginas que esta estructura existe para sostener son tus páginas de zona — mira Páginas de barrio que sí posicionan.

Datos estructurados

Los datos estructurados ayudan a los buscadores a entender qué es una página. No mejoran el posicionamiento por sí mismos, y añadirlos no garantiza resultados enriquecidos — la documentación de Google es constante en que ser elegible para un resultado enriquecido no es tener derecho a él.

Vale la pena implementar en la mayoría de webs inmobiliarias:

• Organization o RealEstateAgent en el sitio, para identificar quién eres
• BreadcrumbList allí donde aparezcan migas de pan
• Article en el contenido editorial
• WebSite para la identidad a nivel de sitio

Ten cuidado con el marcado de propiedades en concreto. Schema.org ofrece tipos relacionados con inmuebles, pero el soporte de resultados enriquecidos inmobiliarios es limitado e irregular según el mercado, y marcar datos que tu MLS restringe puede chocar con tu acuerdo de visualización. Confirma ambas cosas antes de invertir en ello.

Core Web Vitals, en términos inmobiliarios

El trabajo de rendimiento en webs inmobiliarias lo domina una lista corta con siempre los mismos culpables.

La fotografía de las propiedades. El mayor con diferencia. Más de veinte imágenes por propiedad, servidas a menudo mucho más grandes que el hueco que ocupan. Sirve tamaños adaptables, usa formatos modernos y carga en diferido todo lo que esté bajo la línea de flotación — con la excepción de la imagen principal, que suele ser el elemento LCP y debe cargarse de inmediato.

Las librerías de mapas. Pesadas, y a menudo cargadas en páginas donde no se ve ningún mapa. Cárgalas bajo demanda.

Los scripts de terceros. Chats, seguimiento, píxeles de remarketing. Cada uno se ejecuta en el hilo principal. Audítalos de vez en cuando; casi todos los sitios acumulan scripts que nadie sabe justificar.

El JavaScript de la búsqueda. El paquete que mueve los filtros y el mapa suele ser lo más grande que descarga un visitante. Rara vez tiene que estar presente en una página de comunidad que no lleva buscador.

Las tipografías. Precarga las fuentes usadas sobre la línea de flotación; deja que el resto espere.

Manejar esto es parte real de lo que hace una plataforma IDX — URL limpias, renderizado, mantener los datos de propiedades al día y la búsqueda rápida son asuntos de plataforma y no cosas que configure un agente. Mira los sitios IDX de RealFoyer.

Cambios de estado de las propiedades

Cuando una propiedad pasa de activa a reservada y luego a vendida, algo tiene que ocurrirle a su URL. No hay respuesta universalmente correcta, y quien te diga lo contrario está describiendo su propio mercado.

Tres estrategias defendibles:

Mantener la URL y actualizar la página. La marca como vendida y conserva los enlaces y el historial que la página haya acumulado. Solo viable donde tu MLS permite mostrar datos de venta.

Redirigir a la página de zona superior. Manda al visitante a algún sitio útil en lugar de a un callejón sin salida. Sensato cuando no se permite mostrar ventas.

Devolver 404 o 410. Honesto y limpio. Cuesta todo lo que la página hubiera acumulado.

Elijas lo que elijas, se sostienen dos cosas: devuelve el código de estado que realmente quieres decir, y limpia los enlaces internos para que el sitio no esté lleno de punteros a páginas retiradas.

La restricción que decide esto no suele ser técnica. Qué puede seguir mostrándose públicamente tras una venta lo fijan tu MLS y tu licencia de datos.

Un orden de diagnóstico

Cuando la indexación pinta mal, trabaja en este orden en vez de adivinar:

1. Search Console → Indexación de páginas. ¿Qué estado, y cuántas URL?
2. Inspección de URL, prueba en vivo. ¿Está tu contenido en el HTML renderizado?
3. robots.txt y meta robots. ¿Hay algo bloqueado que no debería estarlo?
4. Etiquetas canónicas. ¿Apuntan a donde pretendes?
5. Enlaces internos. ¿Está la página enlazada desde algún sitio?
6. Estadísticas de rastreo. ¿Qué proporción de peticiones va a URL de filtro?

La mayoría de los casos se resuelven en los tres primeros.

Preguntas frecuentes

¿El contenido duplicado del MLS significa que mis propiedades no pueden posicionar? Las fichas rara vez posicionan de forma competitiva, porque todos los participantes muestran los mismos registros. Eso es un problema de singularidad, no una penalización. Tu posicionamiento viene del contenido de zona y de recursos que solo tú tienes.

¿Debo poner en noindex mis páginas de búsqueda? No automáticamente. Las URL de filtro que coinciden con demanda de búsqueda real — una ciudad, un tipo de propiedad — suelen ser tus mejores páginas de entrada. Las que no necesitan indexarse son los órdenes de clasificación y las combinaciones de filtros profundas.

¿Es malo el JavaScript para el SEO inmobiliario? No, Google renderiza JavaScript. Pero el renderizado va en cola en vez de ser instantáneo, y no todos los rastreadores lo ejecutan, así que renderizar en servidor el contenido que importa sigue siendo la opción más segura.

¿Necesito schema para mis propiedades? El marcado de Organization, migas de pan y artículo son victorias sencillas. El marcado a nivel de propiedad es más complicado: el soporte de resultados enriquecidos es irregular, y tu MLS puede restringir el marcado de ciertos campos. Comprueba ambas cosas antes.

¿Cuánto debería tardar la indexación? Varía según el sitio y según lo bien enlazada que esté la página. En vez de mirar el calendario, comprueba si la página se descubre y se renderiza correctamente — esa es la parte que controlas.

¿Debo borrar las propiedades vendidas? No necesariamente, y puede que no sea decisión tuya. Donde tu MLS permita conservar la página, mantener una URL útil suele ser mejor que eliminarla. Donde no lo permita, redirige o devuelve un 404 en condiciones.

En resumen

El SEO técnico en una web inmobiliaria se reduce a tres preguntas: ¿pueden los buscadores descubrir tus páginas?, ¿existe tu contenido en el HTML renderizado?, y ¿está yendo el rastreo a páginas que importan en vez de a permutaciones de filtros sobre el mismo inventario?

Arregla eso y el trabajo de contenido tendrá dónde aterrizar. Sáltatelo y la mejor página de barrio que escribas en tu vida se quedará en Detectada, actualmente sin indexar.

Descubre los sitios IDX de RealFoyer, o reserva una demo para revisar la arquitectura de tu sitio actual.

Lecturas relacionadas

• SEO inmobiliario: la guía completa
• SEO inmobiliario: tus primeros 90 días
• AEO inmobiliario: cómo aparecer en la búsqueda con IA
• Sitios IDX inmobiliarios: la guía completa
• Páginas de barrio que sí posicionan
• Cumplimiento de MLS e IDX: qué debe resolver tu web inmobiliaria

Integridad de la investigación

Escrito el 16 de agosto de 2026 a partir de la propia documentación de Google. La secuencia rastreo-renderizado-indexación, la afirmación sobre el renderizado con Chromium sin interfaz, la salvedad de la cola de renderizado y la recomendación de prerrenderizado proceden de los fundamentos de SEO para JavaScript de Google. Las indicaciones sobre canónicas, incluido que no son obligatorias, proceden de la documentación de Google sobre consolidación de URL duplicadas. La advertencia sobre «espacios de URL infinitos» y la eficacia relativa del robots.txt frente a las etiquetas canónicas proceden de las indicaciones de Google sobre navegación por facetas. No se afirma que el schema mejore el posicionamiento ni que garantice resultados enriquecidos, y no se indica ningún plazo de indexación, porque ninguna de las dos cosas está respaldada. Las citas de la documentación de Google están traducidas del inglés; los originales están en los enlaces anteriores.

Traducción al español del artículo original en inglés. En caso de discrepancia, prevalece la versión en inglés.