El SEO inmobiliario empieza en el inventario, no en una lista de palabras clave. Una propiedad, un edificio, una promoción, una oficina y un agente son entidades distintas. Si el sitio las mezcla, una misma vivienda puede aparecer en varias URLs, las páginas de zona quedan desactualizadas y el equipo no sabe qué consulta terminó en una oportunidad válida.
Una fuente de verdad para cada entidad
La auditoría debe comenzar con el sistema que gobierna cada dato. El feed de inventario puede controlar precio y disponibilidad. El CRM puede ser la fuente de agentes y oficinas. El CMS puede conservar las descripciones editoriales de zonas. Cada campo necesita propietario, frecuencia de actualización y una regla para resolver conflictos.
| Entidad | Dato estable | Cambio que debe propagarse |
|---|---|---|
| Propiedad o unidad | Identificador interno, dirección normalizada | Precio, estado, agente, imágenes y fecha de actualización |
| Edificio o promoción | Nombre y ubicación | Unidades disponibles, servicios y fase |
| Zona | Área geográfica definida | Inventario enlazado y datos locales con fecha |
| Oficina | Dirección, teléfono y área atendida | Horario, equipo y servicios presenciales |
| Profesional | Nombre, licencia cuando aplique y perfil | Oficina, especialidad, disponibilidad y salida de la empresa |
Decidir qué ocurre cuando cambia una propiedad
Una ficha retirada no debería quedar activa con precio antiguo ni redirigir de forma automática a una búsqueda irrelevante. La decisión depende de si la URL conserva utilidad. Una propiedad vendida puede mantener valor si explica el estado, conserva datos permitidos y enlaza alternativas comparables. Una ficha creada por error o sin sustituto puede requerir un estado 404 o 410 real. Si existe un reemplazo inequívoco, una redirección permanente puede ser adecuada.
La plantilla debe mostrar la fecha de actualización y no ocultar el estado detrás de JavaScript. Los enlaces importantes tienen que ser elementos <a href> rastreables. Google documenta esta condición en su guía de enlaces rastreables.
Un registro de cambios permite comprobar qué URL se creó, cuál se retiró y qué respuesta HTTP ofrece. Ese registro es más útil que contar páginas publicadas sin revisar su estado.
Páginas de zona que ayuden a tomar una decisión
Una página local necesita evidencia propia. Puede reunir inventario actual, límites geográficos claros, transporte, servicios cercanos y una explicación editorial de cómo se organiza la oferta. Los datos deben indicar fuente y fecha. Cambiar el nombre de la ciudad dentro de un texto idéntico no aporta esa evidencia.
La relación con el inventario debe ser bidireccional. La zona enlaza propiedades vigentes y cada ficha vuelve a su zona, edificio u oficina correspondiente. Así, el usuario puede pasar de contexto a disponibilidad sin depender de un buscador interno.
Antes de publicar
Confirmar límites, nombre local, fuente de datos, responsable editorial y conjunto real de propiedades relacionadas.
Después de publicar
Revisar búsquedas, clics, inventario vacío, enlaces rotos y cambios operativos en la zona.
Controlar filtros sin perder rutas útiles
Precio, dormitorios, servicios, estado y orden pueden multiplicar combinaciones. No todas merecen una URL indexable. El equipo debe definir una lista cerrada de páginas de demanda que tendrán contenido, enlaces internos y canonical propio. Las demás combinaciones pueden seguir siendo útiles para el usuario sin convertirse en páginas de destino orgánicas.
Google advierte que la navegación facetada puede consumir recursos de rastreo y crear espacios de URL muy grandes. Su documentación sobre navegación facetada describe opciones para evitar el rastreo de combinaciones innecesarias. La solución concreta depende de cómo el servidor y la interfaz generan las URLs.
Oficinas y agentes representados con precisión
Las páginas locales y los perfiles externos deben coincidir con la operación real. Nombre, dirección, teléfono, horario y categoría no son campos para insertar palabras clave. Las directrices de Google Business Profile explican cómo representar empresas, departamentos y profesionales.
El marcado LocalBusiness puede describir información visible, pero no corrige datos contradictorios. Google indica las propiedades admitidas en su guía de datos estructurados para negocios locales. El HTML visible, el marcado y el sistema operativo deben decir lo mismo.
Separar consulta, contacto y oportunidad
Search Console muestra visibilidad y clics. La analítica del sitio puede registrar un formulario enviado o un botón pulsado. El CRM determina si hubo contacto, si la consulta correspondía al mercado atendido y si se convirtió en una oportunidad. Mezclar esos estados infla la captación y oculta problemas de calidad.
El informe debe conservar URL de entrada, tipo de propiedad o zona, identificador de campaña cuando exista, estado del consentimiento y resultado operativo. Los equipos pueden comparar páginas y rutas sin atribuir una venta a una sola visita ni exponer información innecesaria.
- Validar que una solicitud de prueba llegue al destino correcto.
- Excluir spam, duplicados y consultas fuera de cobertura.
- Conciliar una muestra de formularios y llamadas con el CRM.
- Anotar cambios de inventario o seguimiento antes de comparar periodos.
Revisar una muestra del inventario
Podemos contrastar el feed, las URLs renderizadas, el enlazado y una muestra de consultas para definir un plan verificable.
Reservar una consulta SEO