Hay proyectos en los que el reto técnico y el reto de negocio son exactamente el mismo problema formulado desde perspectivas distintas. El caso de Rehabmedic es uno de ellos. Se trataba de lanzar una nueva unidad de negocio —el alquiler de equipamiento de rehabilitación médica— con un plazo de puesta en marcha ajustado, una infraestructura heredada que no estaba dimensionada para soportar el crecimiento previsto, y la necesidad de posicionamiento orgánico desde el primer día. Lo que sigue es la descripción técnica y de negocio de cómo se resolvió.
El reto: visibilidad cero, infraestructura frágil, plataforma fragmentada
Una nueva unidad de negocio sin presencia digital
Rehabmedic es una empresa del sector de la salud y el equipamiento de rehabilitación con presencia consolidada en su mercado. Al lanzar la unidad de alquiler de equipamiento médico —un segmento distinto al de venta, con su propio proceso comercial, su propia lógica de facturación y su propio público objetivo— no existía ninguna presencia digital específica para ese servicio. El cliente potencial que buscaba en Google «alquilar cama articulada» o «alquiler silla de ruedas eléctrica» no encontraba a Rehabmedic. La visibilidad era literalmente cero.
El coste de oportunidad era inmediato y cuantificable: cada semana sin posicionamiento era una semana de demanda que iba a la competencia. No había tiempo para construir autoridad de dominio de forma orgánica a lo largo de meses; había que encontrar la palanca técnica correcta para acelerar la indexación y el posicionamiento desde el primer momento.
Infraestructura heredada sin alta disponibilidad
La infraestructura existente presentaba un perfil de riesgo que no era compatible con el crecimiento previsto. Los puntos de fallo eran identificables: sin replicación de base de datos, sin mecanismos de failover automático, sin observabilidad proactiva. Una caída del sistema en un momento de pico de tráfico o durante una campaña de captación no tenía un tiempo de recuperación garantizado.
Para una empresa del sector salud en la que los clientes pueden estar buscando equipamiento de forma urgente —alta hospitalaria, recuperación postoperatoria— el tiempo de inactividad tiene un coste directo en experiencia de usuario y, en consecuencia, en conversión y reputación.
Plataforma fragmentada: Navision y Magento como punto de partida
El stack tecnológico de partida estaba compuesto por dos sistemas que tampoco se comunicaban de forma fluida:
- Microsoft Dynamics NAV (Navision) para la gestión ERP: contabilidad, inventario, proveedores y la operativa del negocio de venta.
- Magento como plataforma de comercio electrónico, desconectada del ERP en gran medida, con sincronización de datos manual o mediante integraciones frágiles.
La nueva unidad de alquiler no podía montarse encima de esta arquitectura sin abordar primero la integración. Y la integración real exigía plantearse si tenía sentido mantener tres plataformas distintas —Navision, Magento y un nuevo sistema para alquiler— o consolidar sobre una arquitectura unificada.
La solución: Odoo Multi-web, Schema.org y arquitectura de alta disponibilidad real
Odoo Multi-web como plataforma unificada
La decisión arquitectónica central fue consolidar sobre Odoo como plataforma única, aprovechando su módulo Multi-web para gestionar de forma independiente la tienda de venta y el nuevo portal de alquiler desde una misma instancia. Esta aproximación ofrecía ventajas concretas:
- Una sola fuente de verdad para el inventario: un producto podía estar disponible para venta y para alquiler simultáneamente, con gestión unificada del stock.
- Procesos diferenciados en el mismo sistema: el flujo de alquiler —contrato, depósito, devolución, facturación periódica— se implementó como extensión de los módulos nativos de Odoo, sin necesidad de un sistema externo.
- Web específica para cada unidad de negocio: el portal de alquiler tenía su propio dominio, su propia identidad visual y su propia arquitectura de contenidos, pero corría sobre la misma instancia Odoo con acceso al mismo ERP.
Schema.org: la palanca de posicionamiento acelerado
Aquí está el corazón técnico del resultado de posicionamiento. La pregunta que había que responder era: ¿cómo consigue un sitio web nuevo —sin autoridad de dominio, sin backlinks, sin historial— posicionarse en el Top 3 de Google para keywords comerciales en menos de 60 días?
La respuesta no estuvo en el SEO convencional de contenidos. Estuvo en la arquitectura de datos estructurados Schema.org implementada desde el primer día en cada página de producto del portal de alquiler. La lógica es la siguiente: Google puede tardar meses en desarrollar confianza en un dominio nuevo, pero puede confiar de forma casi inmediata en un sitio que le habla en su idioma — y el idioma que Google prefiere para entender el contenido es Schema.org.
Se implementaron los siguientes tipos de marcado:
- Product con
offers,availability,priceValidUntilyaggregateRatingen cada página de producto de alquiler. - Organization con información completa de la empresa, coordenadas de contacto y enlaces a redes sociales.
- LocalBusiness con área de servicio geográfica y horarios de disponibilidad.
- FAQPage en las páginas de categoría, respondiendo a las preguntas más frecuentes sobre el proceso de alquiler.
- BreadcrumbList en toda la jerarquía de navegación para facilitar el rastreo y la comprensión estructural del sitio.
El resultado fue que Google pudo entender, desde los primeros rastreos, exactamente qué era cada página, qué producto ofrecía, a qué precio, con qué disponibilidad y en qué área geográfica. Sin ambigüedad, sin inferencia. Los rich snippets aparecieron en los resultados casi de forma inmediata, lo que aumentó el CTR orgánico y retroalimentó el posicionamiento.
«El ERP bien montado no es solo operativa interna: es también una máquina de posicionamiento cuando los datos fluyen correctamente hasta la capa web.»
Alta disponibilidad: réplica PostgreSQL en vivo
Para resolver el riesgo de infraestructura, se diseñó e implementó una arquitectura de alta disponibilidad con replicación PostgreSQL streaming en tiempo real. Los elementos clave:
- Réplica PostgreSQL en vivo: un servidor secundario recibe el WAL (Write-Ahead Log) del primario de forma continua, manteniendo una copia actualizada en tiempo real. Si el nodo primario falla, la réplica puede promoverse a primario en un tiempo controlado.
- Balanceo de carga para lecturas: las consultas de solo lectura —la mayoría del tráfico web— se distribuyen entre primario y réplica, reduciendo la carga sobre el servidor principal.
- Failover supervisado: el proceso de promoción de réplica está documentado y testado, con un tiempo de recuperación definido y reproducible.
Esta arquitectura garantizó que durante los picos de tráfico —campañas, alta hospitalaria estacional, eventos— el sistema mantuviera rendimiento sin degradación perceptible para el usuario final.
Observabilidad con bots de Telegram
El componente de observabilidad merece mención específica porque fue uno de los elementos que marcó la diferencia en la operativa real. Se implementó un sistema de alertas proactivas mediante bots de Telegram integrados con la monitorización del sistema. El enfoque fue pragmático: no se trata de tener el dashboard más sofisticado, sino de que cuando algo falla o está a punto de fallar, la persona responsable lo sepa en segundos, no en horas.
Las alertas cubren múltiples capas:
- Carga del servidor y uso de memoria con umbrales configurables.
- Estado de la réplica PostgreSQL: retraso de replicación, conexión del WAL receiver, longitud de la cola de sincronización.
- Errores críticos en los logs de Odoo: worker crashes, timeouts de base de datos, fallos en cron jobs.
- Disponibilidad del sitio web: verificaciones HTTP periódicas con alerta inmediata si el tiempo de respuesta supera el umbral o el sitio devuelve un error.
El resultado es una postura de operaciones proactiva: los problemas se detectan y resuelven antes de que el usuario final los experimente.
Migración de Navision y Magento
La migración desde Navision a Odoo se planificó como un proceso en fases para evitar el corte operativo total. La contabilidad, el inventario y la gestión de clientes se migraron con un período de operación paralela controlada, validando la integridad de los datos en cada etapa antes de desconectar el sistema origen.
La migración desde Magento presentó el reto habitual de este tipo de plataformas: un esquema de datos de producto y categorías con una estructura propia que no mapea directamente sobre el modelo de Odoo. Se desarrollaron scripts de transformación específicos para los maestros de productos, las categorías, el historial de pedidos y los clientes registrados, con validación cruzada de registros para garantizar la integridad referencial.
El criterio de éxito para ambas migraciones fue el mismo: zero downtime operativo. La tienda no estuvo cerrada en ningún momento del proceso. Los pedidos durante el período de migración se procesaron sin interrupción.
Resultados: métricas reales
Top 3 Google orgánico en 60 días
El resultado más llamativo y el que más preguntas genera: el portal de alquiler de Rehabmedic alcanzó posiciones en el Top 3 de Google para las keywords objetivo en el mercado español en menos de dos meses desde el lanzamiento. Sin inversión en publicidad de pago. Sin campaña de link building. Únicamente con la arquitectura técnica correcta: Schema.org completo desde el día uno, velocidad de carga optimizada, estructura de URL limpia y contenido de producto bien descrito.
Este resultado no es reproducible aplicando cualquier táctica SEO estándar. Es el resultado de que la plataforma —Odoo con la arquitectura de datos estructurados bien implementada— le habla a Google de forma que Google entiende y premia.
Cero tiempo de inactividad en picos de tráfico
Durante el período de operación posterior al lanzamiento, incluyendo picos de tráfico por campañas y momentos de alta demanda estacional, la plataforma mantuvo disponibilidad completa. La réplica PostgreSQL en vivo absorbió la carga de lectura adicional sin impacto en el rendimiento del nodo primario. Las alertas de Telegram permitieron resolver incidencias menores de forma proactiva, antes de que llegaran a afectar al usuario.
Plataforma unificada operativa
La sustitución de Navision y Magento por Odoo eliminó la fricción operativa de gestionar múltiples sistemas. El equipo de operaciones trabaja sobre una sola interfaz para gestión de inventario, facturación, CRM y contenidos web. El coste de mantenimiento de dos sistemas adicionales —licencias, integraciones, formación— desapareció del P&L.
Lecciones técnicas aplicables a tu proyecto
1. Schema.org no es un detalle de SEO: es arquitectura de datos
La mayoría de los equipos trata Schema.org como un elemento de optimización on-page que se añade «cuando hay tiempo». En proyectos donde la visibilidad orgánica es crítica desde el lanzamiento, Schema.org debe ser parte del diseño de la plataforma, no un ajuste posterior. Si Odoo es tu plataforma, los datos del producto ya existen en el ERP: solo hay que hacer que fluyan correctamente hasta el marcado HTML.
2. Alta disponibilidad no es opcional para negocios con picos de demanda
La replicación PostgreSQL streaming no es una arquitectura exótica ni cara. Es la respuesta correcta al riesgo de pérdida de negocio por caída del sistema. El coste de implementarla es muy inferior al coste de una caída durante un pico de tráfico en un sector donde la urgencia del cliente es real.
3. La migración de ERP tiene que ser invisible para el cliente final
Un proceso de migración que interrumpe la tienda durante horas o días tiene un coste directo en ventas y en reputación. La planificación de la migración en fases, con operación paralela y criterios de validación claros antes de cada corte, es la única forma de garantizar que el cliente final no nota el cambio.
4. La observabilidad proactiva es más barata que la recuperación reactiva
Un bot de Telegram que alerta cuando la réplica PostgreSQL lleva más de 30 segundos de retraso cuesta horas de configuración. Un incidente de caída de base de datos sin monitorización proactiva puede costar días de recuperación y pérdidas comerciales medibles. La relación coste-beneficio es obvia.
5. Odoo Multi-web permite escalar unidades de negocio sin multiplicar la complejidad operativa
Cuando el negocio crece y aparece una nueva línea de producto, un nuevo mercado geográfico o un nuevo canal de distribución, la respuesta habitual es añadir otra plataforma. Con Odoo Multi-web, la respuesta es añadir un nuevo sitio sobre la misma instancia, con acceso al mismo ERP y los mismos datos, sin duplicar la infraestructura ni multiplicar los costes de mantenimiento.
¿Tienes un proyecto similar?
Si tienes un proyecto de lanzamiento de nueva unidad de negocio, una migración de Navision o Magento pendiente, o una infraestructura que no está preparada para el siguiente nivel de crecimiento, puedo revisar tu situación y decirte qué arquitectura tiene sentido para tu caso concreto. Sin humo. Sin propuestas de 80 páginas que tardan tres meses en ejecutarse.