El sitio que llevaba cuatro meses sin poder publicar una propiedad.
Cuando Juan Carlos me contactó, el pedido era simple: “no puedo subir las fotos de las propiedades”.
Era un WordPress. Suena a media hora de trabajo.
Terminó siendo la reconstrucción completa del sitio. Y el motivo por el que valió la pena contarlo no es técnico: es que durante cuatro meses una corredora estuvo perdiendo oportunidades comerciales sin que nadie lo hubiera medido.
Antes de tocar nada, medir
Hay una tentación fuerte cuando alguien te dice “no funciona esto”: entrar y arreglarlo. Resistirla es la parte más rentable del trabajo.
Lo primero que hice fue pedir un respaldo del contenido y leerlo. No el sitio: los datos.
Ahí apareció el primer dato duro. La última imagen cargada con éxito databa del 2 de abril. Habían pasado cuatro meses.
En la papelera había propiedades creadas y descartadas en los días previos a que me escribieran. Intentos de publicar que terminaban en nada, repetidos, sin que nadie entendiera por qué.
Sabían que “el sitio andaba raro”. No sabían que llevaban un tercio del año sin poder incorporar inventario nuevo a su vitrina principal.
El diagnóstico completo
Siguiendo el hilo apareció el resto:
- Un error crítico visible para los visitantes en un módulo lateral del sitio
- La versión de PHP del servidor desactualizada, incompatible con varios componentes
- Siete complementos sin actualizar, tres de ellos abandonados por sus autores hace años
- Las 2.499 imágenes de la biblioteca servidas por http, generando contenido mixto y advertencias del navegador
- El archivo robots.txt bloqueando el acceso de los buscadores
- 2.096 de esas imágenes sin asociación a ninguna propiedad: años de subidas fallidas acumuladas
- La base de datos contaminada con metadatos redundantes generados por un error de programación del tema
- Y una sorpresa: un número de celular personal publicado dentro de la descripción de una propiedad
Cualquiera de esos puntos justifica una intervención. Ninguno era la causa raíz.
La causa raíz
El sitio usaba un tema comercial de real estate comprado alrededor de 2014. Diez años sin actualizaciones, descontinuado por su autor.
Eso por sí solo no es fatal. Muchos sitios funcionan con temas viejos.
El problema era otro: ese tema era lo único que hacía existir las fichas de propiedad.
En WordPress, un tipo de contenido personalizado —en este caso, las propiedades— existe solo mientras algo lo declare en el código. Aquí lo declaraba el tema. Los campos de precio, superficie, dormitorios y baños también.
Consecuencia directa: al desactivar el tema, las 28 propiedades seguían guardadas en la base de datos, pero WordPress dejaba de saber qué eran. No aparecían en el sitio ni en el escritorio.
Eso explica por qué nadie lo había tocado en una década. Probablemente alguien lo intentó, vio desaparecer el catálogo completo, y decidió no volver a intentarlo.
Y el cargador de imágenes de ese tema estaba escrito para una API de medios de WordPress que ya no existe. Ahí estaba la falla que originó la llamada.
Parchar o reconstruir
Se podía intentar un parche: actualizar PHP, esperar que reviviera el cargador, cruzar los dedos. Barato, rápido, y con el problema estructural intacto.
O reconstruir sobre una base que no dependiera de un componente muerto.
Elegí lo segundo, y el paso clave fue este: registrar el tipo de contenido de propiedades desde un plugin propio, no desde el tema.
Suena menor. Cambia todo. Con eso el sitio deja de ser rehén de una pieza de software abandonada: se puede cambiar de tema, de constructor o de diseño sin perder el inventario. La próxima persona que tome este sitio en cinco años no va a enfrentar el mismo callejón sin salida.
El trabajo
Migración. El hosting también estaba desordenado: los servidores de nombres apuntaban a un lugar distinto al que indicaba el correo de activación, y la base de datos vivía bajo una cuenta que no correspondía al dominio. Cuenta nueva, instalación limpia.
Contenido. Las 28 propiedades trasladadas con sus datos y descripciones, previa depuración de las firmas internas de los corredores y del celular publicado.
Normalización. Esta parte no se ve, pero es la que hace funcionar el buscador. Los precios eran texto libre: UF 7.700, CLP $ 429.000.000, 49900000, $37.900.000.-. Las comunas convivían escritas de tres formas distintas, con una con falta de ortografía incluida. Las superficies mezclaban metros cuadrados y hectáreas en el mismo campo.
Un script convirtió todo eso en valores numéricos comparables. Sin ese paso, ningún filtro de precio puede funcionar.
Diseño. Responsive —el sitio anterior no lo era, y ahí está la mayoría del tráfico—, buscador con filtros por operación, comuna, tipo y precio, y ficha de propiedad con galería y contacto directo por WhatsApp.
Arquitectura de contenido. Esta fue la parte más interesante. Revisando el menú del sitio viejo aparecieron servicios que la corredora ofrecía y que no estaban trabajados en ninguna parte: permutas, derechos de aprovechamiento de agua, propiedades con acceso a lago o río. Son búsquedas con intención altísima y competencia casi nula en la zona lacustre. Estaban ahí, enterradas en un menú desplegable, sin una sola línea de contenido.
Tres cosas que me llevo
El síntoma casi nunca es el problema. El pedido era subir fotos. La causa era una dependencia estructural de software abandonado. Si hubiera empezado a trabajar sobre el pedido, habría gastado el presupuesto sin resolver nada.
Nadie mide lo que le duele. Cuatro meses sin publicar propiedades es una pérdida comercial concreta y cuantificable. No estaba cuantificada. El dato apareció recién cuando abrí el respaldo, y fue el argumento más fuerte de todo el proyecto.
El costo de no tener mantención se paga junto y tarde. Este sitio no falló de un día para otro. Se fue apagando durante años: un plugin que dejó de actualizarse, una versión de PHP que quedó atrás, un tema que su autor abandonó. Ninguno de esos eventos dolió cuando ocurrió. Todos se cobraron al mismo tiempo.