Victor Arias
Un distribuidor de productos para la salud tenía la web nueva en staging comportándose como una tienda: carrito, checkout y precios propios cuando la venta se hace en su tienda externa. En cinco días se convirtió en web informativa: la compra deriva a la tienda con redirecciones 301, se corrigieron las categorías regulatorias de las fichas (un complemento aparecía como micronizado y una crema tópica como complemento oral), se ocultó el blog de relleno, se sustituyeron los datos de contacto y se reescribieron las páginas legales, con consentimiento y una base SEO en el tema. El TTFB bajó de 2,6–3,0 s a 0,54–0,66 s en páginas cacheadas y el HTML de 99 KB a 17 KB.
| Cliente | Distribuidor de productos para la salud |
| Confidencialidad | Se omiten el nombre del cliente, las capturas y los enlaces por acuerdo de confidencialidad. Los diagramas describen la solución y las técnicas aplicadas. |
| Sector | Salud y parafarmacia |
| Servicio | Desarrollo WordPress |
| Tecnologías | WordPress, WooCommerce (solo catálogo), Elementor Pro, Tema hijo, Cache Enabler, SEO en el tema, GA4 con consentimiento, gzip y cabeceras, SSH/SCP |
| Duración | 5 días |
| Nuestro rol | Auditoría de la web en staging y adaptación de tienda a web informativa: modelo de compra, contenido de producto, home, blog y contacto, páginas legales, consentimiento, SEO técnico y rendimiento. |
| Publicado | 20 de octubre de 2026 |
Un distribuidor de productos para la salud tenía la web nueva en staging, a punto de lanzarse, y seguía comportándose como una tienda: carrito, checkout, «Mi cuenta», precios y botones de compra, cuando la venta se hace en su tienda externa. La web no vendía, pero tampoco informaba: las fichas describían los productos con la categoría equivocada y las páginas legales hablaban de una tienda que no era esa.
El trabajo no fue un rediseño, sino una puesta a punto antes del lanzamiento: cambiar el modelo de compra, corregir el contenido regulatorio, adaptar las páginas legales y dejar una base técnica y SEO que no existía. En cinco días, en staging y con backups, la web quedó lista para publicarse. Por acuerdo de confidencialidad no se nombra al cliente ni a los productos.
El reto: una web que vendía sin ser la tienda
El dominio definitivo aún no existía: todo se probaba en un staging. Eso daba margen para cambiar, pero también significaba que cada error iba a llegar al lanzamiento si nadie lo corregía.
La compra estaba en el sitio equivocado
El botón «Comprar» bajaba a una sección de la propia home y las fichas tenían precio, selector de cantidad, carrito y «Mi cuenta». La venta real se hace en la tienda del distribuidor, así que cada paso de compra en esta web era un callejón sin salida: el usuario podía llenar un carrito que no iba a ninguna parte.
Dos productos, dos categorías mal explicadas
Una cosa es un complemento alimenticio y otra un producto sanitario de uso tópico, y la web los trataba igual. Un complemento aparecía como «micronizado, 2 micras» cuando el producto es ultramicronizado, y una crema de uso tópico se describía como un complemento oral con vitaminas y minerales que no le corresponden. Había además claims publicitarios y faltaban advertencias.
Plantilla, legal y técnica
El blog tenía ocho entradas y ocho categorías de relleno, el contacto mostraba un teléfono ficticio y las páginas legales citaban la tienda como si fuera este sitio: la privacidad mostraba el aviso legal y las condiciones eran de compra, fechadas en 2022. En lo técnico, título duplicado, sin meta descripción, sin H1, sin textos alternativos, sin Open Graph, un TTFB de 2,6–3,0 s y desbordamiento horizontal en móvil.
El diagnóstico: no era un problema de diseño
Los fallos venían de tres decisiones anteriores al diseño: qué modelo de negocio tiene la web, cómo se describe un producto regulado y qué papel juega el CMS. Ninguna se arregla con CSS.
El modelo: informar, no vender
Si la venta está en otra tienda, la web tiene que llevar allí. WooCommerce puede quedarse para la ficha —datos, presentación, advertencias—, pero sin carrito, sin checkout y sin cuenta. La compra tiene un solo destino y el camino no debe tener pasos intermedios.
La categoría: el lenguaje cambia el régimen
Un complemento alimenticio no puede describirse como medicamento y un producto sanitario tópico no puede presentarse como suplemento oral. El texto, las advertencias y los claims tenían que seguir el material del distribuidor, que es quien responde ante la autoridad sanitaria. Y lo técnico se arregla en el tema: con cinco páginas, añadir un plugin de SEO era sumar peso y dependencias para lo que el child theme ya podía hacer.
La solución: qué cambió en la web
Los cambios se hicieron por puntos, con backup previo y verificación después, para que cada uno pudiera revertirse sin arrastrar a los demás.
La compra, fuera de la web
El menú y los botones llevan a la tienda del distribuidor, y cada producto tiene su enlace directo. Se eliminaron carrito, usuario, precio y cantidad, y las URLs de carrito, checkout, cuenta y tienda redirigen con 301 a la tienda, para no dejar rutas muertas ni contenido duplicado.
Las fichas, con la categoría correcta
La ficha del complemento se corrigió a ultramicronizado y se completó con presentación, código nacional, modo de empleo, fabricante, distribuidor y advertencias. La del producto tópico se rehizo como crema, con su composición, su modo de empleo y sus advertencias, y se eliminaron las referencias orales. En la home se corrigieron enlaces, se quitó el párrafo duplicado y los claims, y la cabecera rotatoria pasó a mostrar producto y botón.
Blog, contacto y legales
El blog se ocultó del menú, se vació y se marcó noindex, fuera del sitemap. El contacto pasó a los datos reales del distribuidor, con formulario y RGPD enlazado. Las páginas legales se reescribieron para una web informativa: privacidad real, condiciones de uso en lugar de compra, aviso, cookies y descargo adaptados, y un dominio dinámico para que la migración no obligue a tocar los textos.
SEO, consentimiento y rendimiento
Un H1 por página, títulos y metadescripciones propios, alt en las imágenes de producto y Open Graph con imagen de 1200 × 630. GA4 no carga hasta que se acepta, y el clic en los enlaces de compra dispara un evento. Se activó caché de página con Cache Enabler, gzip y cabeceras, excluyendo el contacto para no cachear el formulario. Y se corrigió el desbordamiento horizontal de los carruseles en móvil.
El modelo, en una línea: la web informa y el botón de compra lleva a la tienda donde se paga.
Cómo lo hicimos en cinco días
Staging, backups y cambios reversibles
Todo se hizo sobre el staging, con copia de la base de datos y del tema antes de tocar nada. El FTP estaba bloqueado desde el entorno de trabajo, así que los archivos se movieron por SSH y SCP. Cada cambio se comprobó en escritorio y en móvil, con capturas antes y después: menú, cabecera, fichas, formulario, aviso de cookies y páginas legales.
Lo que quedó del lado del cliente
El código deja preparadas las piezas que dependen de decisiones del cliente: el ID de GA4, el token de Search Console, la prueba real del formulario y el dominio definitivo. Las legales se resolvieron con un dominio dinámico, así que la migración no obliga a reescribirlas; solo hay que limpiar la caché para regenerar las URLs.
Tres medidas del mismo staging: tiempo de respuesta en caché, peso del HTML con gzip y ancho del cuerpo en móvil.
Resultados
La web dejó de vender y empezó a informar: la compra deriva a la tienda, las fichas describen la categoría real de cada producto y las legales son coherentes con una web que no vende.
| Área | Antes | Después |
| Compra | Carrito, checkout, cuenta y precios propios | Todo deriva a la tienda; 301 en las rutas de tienda |
| Fichas | Categoría equivocada y datos incompletos | Categoría correcta, datos, modo de empleo y advertencias |
| Blog | Ocho entradas y ocho categorías de relleno | Oculto, vacío, noindex y fuera del sitemap |
| Contacto | Teléfono y email de plantilla | Datos reales del distribuidor y formulario con RGPD |
| Legal | Textos de tienda y dominio ajeno | Textos de web informativa y dominio dinámico |
| SEO | Sin título único, meta, H1, alt ni Open Graph | Un H1, títulos, metadatos, alt y Open Graph |
| Rendimiento | TTFB 2,6–3,0 s y HTML de 99 KB | 0,54–0,66 s en caché y 17 KB con gzip |
| Móvil | Desbordamiento horizontal (1.574 px) | Sin desbordamiento (375 px) |
El rendimiento es el dato más visible: el TTFB pasó de 2,6–3,0 s a 0,54–0,66 s en páginas cacheadas y el HTML de 99 KB a 17 KB con gzip. El primer acceso, sin caché, sigue en 2,6 s: eso ya depende del alojamiento, no del código, y queda como recomendación revisar hosting o CDN.
Qué revisar si tu web está a punto de lanzarse
Estos son los puntos que, en nuestra experiencia, convierten una web «terminada» en una web publicable:
- El botón de compra, ¿lleva a la tienda o a un carrito? Si la venta está fuera, que el camino no tenga pasos intermedios y que las rutas antiguas redirijan con 301.
- ¿La categoría del producto está en el texto? Complemento alimenticio, producto sanitario, medicamento y cosmético no son lo mismo: cambian el lenguaje, las advertencias y lo que se puede prometer.
- ¿Las legales hablan de esta web? Si citan otra tienda, o son condiciones de compra de una web que no vende, no sirven.
- ¿Hay un H1 y un título único por página? Antes de añadir plugins, comprueba lo que el tema ya puede resolver.
- ¿La analítica espera al consentimiento? Si GA4 carga antes de aceptar, el banner no sirve de nada.
- ¿El TTFB depende del hosting? La caché arregla la segunda visita; la primera es infraestructura.
Si tu web está en staging y no sabes si está lista para publicarse, en la página de desarrollo WordPress contamos cómo trabajamos, y si prefieres revisar tu caso concreto puedes escribirnos.
Preguntas frecuentes
¿Por qué no hacer una web nueva en vez de adaptar la que había?
Porque el catálogo, las fichas, las imágenes y las URLs ya estaban construidos y probados: adaptarlos cuesta menos que rehacerlo y no se pierde lo que ya funciona. Una web nueva habría duplicado contenido y obligado a reescribir las legales y los textos de producto. La adaptación se hizo en staging, punto por punto y con backups, así que cada cambio era reversible.
¿No se pierde la venta si la compra sale de la web?
No: la venta la hace la tienda del distribuidor, y esta web es el escaparate que lleva allí. Lo que se pierde es el paso intermedio que no funcionaba, un carrito que no podía cobrar. Además, el clic en cada botón de compra se mide como evento, así que se sabe cuánta gente sale hacia la tienda y desde qué ficha.
¿WooCommerce sigue haciendo falta si no se vende?
Puede servir como catálogo: guarda la ficha, los atributos y la presentación sin carrito ni checkout. Si el catálogo es pequeño, los campos del propio tema bastan y se puede prescindir del plugin; en este caso se conservó porque las fichas ya estaban montadas sobre él. La regla es que no quede ningún camino de compra dentro de la web.
¿Qué riesgo hay en cambiar el lenguaje de un producto regulado?
Mucho, si no se parte del material del titular. Un complemento alimenticio no puede prometer lo que un medicamento, y un producto sanitario tópico no se describe como suplemento oral: cambian las advertencias y lo que se puede afirmar. Por eso los textos se alinearon con los del distribuidor, que es quien responde ante la autoridad sanitaria, y se eliminaron los claims publicitarios.
¿Por qué el TTFB no baja en la primera visita?
Porque la caché sirve páginas ya generadas: la primera petición sigue ejecutando PHP y consultando la base de datos. En este caso, la caché bajó el TTFB a 0,54–0,66 s, pero el primer acceso seguía en 2,6 s. Bajar de ahí exige revisar el alojamiento o poner un CDN delante: es infraestructura, no código.
