Piscinas Chisvert:
De un WordPress abandonado a una web rápida y sin deuda técnica

El negocio tiene una especialidad con mucho encaje comercial: la limpieza profunda y el rejuntado de piscinas. La web no la mencionaba. Lo que sí tenía eran los restos de un trabajo a medias:

• La página de contacto hablaba de otra empresa. Era un resto de plantilla con una razón social ajena, justo en la página que más importa para convertir.
• El banner de cookies mostraba marcadores sin sustituir en lugar de texto real.
• Faltaban descripciones en varias páginas, y muchas imágenes no tenían texto alternativo o tenían el nombre del archivo.
• 20 MB de fotos sin formatos modernos, mezcladas con imágenes de stock genéricas.
• Un blog vacío, con solo la entrada de ejemplo de WordPress ofrecida a Google como contenido.
• Plugins sin actualizar durante años en un sitio en producción.
• El correo de contacto no lo leía nadie. El cliente usaba otra cuenta y el correo de la web apuntaba a un servidor antiguo.

En total, 8 páginas reales y 97 URLs rastreables, entre sitemaps, feeds, imágenes y direcciones técnicas. No había métricas históricas de tráfico para comparar, así que este caso habla de lo que construí y de lo que medí en la web nueva.

Antes de tocar nada comparé dos caminos: una web nueva completa en el mismo dominio, o mantener la actual y crear otro dominio solo para limpieza y rejuntado. Gana el primero:

• Especializar no exige otro dominio. Se consigue con URLs, navegación, copy y recorrido de conversión.
• Dos dominios reparten las señales de enlaces, reseñas y autoridad. Un solo negocio, una sola ficha de Google y una sola entidad.
• Parchear WordPress era más caro que rehacerlo. Actualizar años de plugins sin acceso al hosting ni entorno de pruebas es un riesgo sin red, y con 8 páginas no compensa mantener un CMS.

Se mantuvieron el dominio, la marca, la ficha de Google y las URLs con valor. Se cambió todo lo demás.

Tres principios desde el primer día: móvil primero (se verifica a 375 px, con botón de llamada siempre accesible), accesibilidad real (HTML semántico, foco visible, contraste revisado a mano) y contenido sin inventar cifras, química ni precios.

El SEO técnico va integrado en la construcción, no como una capa posterior: un propietario por intención de búsqueda, un <h1> por página, un hub propio para la limpieza y el rejuntado, y datos estructurados JSON-LD con nombre, dirección, teléfono y área de servicio definidos en un único sitio. Una sola página de zonas de servicio, en lugar de una por municipio, porque una página local solo se justifica cuando tiene contenido propio.

Cada URL de la web antigua tiene un destino decidido y un test automático que lo comprueba: 17 responden 200 directamente, 69 redirigen con 301 y el resto da 404 de forma deliberada. Las reglas:

• Redirección 301 solo donde existe un equivalente real. Nunca masiva a la home, que Google trata como un error blando.
• 404 propio para lo que no tiene equivalente, como el blog de prueba, los feeds y las direcciones técnicas.
• Los sitemaps antiguos apuntan al nuevo, porque Search Console los tiene registrados.

El cambio de DNS y de correo se hizo con un guion de pasos y puntos de control automáticos, con vuelta atrás definida. Primero la zona DNS (de 26 registros importados, casi todos restos del servidor antiguo, quedaron 3, más DMARC), luego el correo, probado con un mensaje a la dirección real y otro a una inventada, y por último la web. El control final recorrió el sitio vivo: DNS, HTTPS, redirección de www, ausencia de noindex, sitemap y las 97 URLs antiguas una a una, con 0 fallos.

Cada cambio pasa por un conjunto de comprobaciones en CI antes de poder fusionarse:

Lo que más me interesa de este sistema es que probé cada filtro metiendo fallos a propósito. Los filtros estáticos detectaron los nueve fallos inyectados, el de datos estructurados los cuatro, y Lighthouse bloqueó un script de terceros y una imagen de 1,4 MB. Así sé que el filtro funciona, en lugar de suponerlo.

• Fotos de la home: de 7,2 MB a 946 KB en móvil. Una sola foto pesaba 2,1 MB para pintarse a 343 px.
• Carga inicial en móvil con conexión lenta: 142 KB y 10 peticiones, frente a unos 1,4 MB y 19 al principio. El vídeo del hero ya no entra en la carga: se inyecta después del evento load y solo si procede, nunca con movimiento reducido, ahorro de datos o conexión lenta.
• Fondos decorativos en diferido y galería de proyectos de 405 KB a 10 KB en la carga inicial.
• Cabeceras de caché corregidas: todo se servía con max-age=0, incluso los ficheros con hash en el nombre.

El LCP de las cabeceras con foto bajó con un recorte vertical propio para móvil, en lugar de escalar una foto apaisada:

Mediana de tres pasadas con el móvil lento simulado de Lighthouse. Por encima de 2,5 s el LCP deja de considerarse bueno.

• El primer inventario se quedó corto. Faltaban 11 imágenes que solo aparecían dentro de hojas de estilo y estilos en línea, que un rastreador que solo sigue enlaces no ve. Lo cazó el cruce con un inventario anterior.
• Una medición estaba mal. La home salió en 74 KB porque la prueba era local, con las tipografías todavía en Google y en caché. Al autoalojarlas salieron 91 KB. Desde entonces comparo siempre con caché fría.
• El póster del vídeo era otra piscina. No se notaba porque el vídeo arrancaba solo. Al diferir el vídeo, se vio entero en conexión lenta. Ahora es el primer fotograma del propio vídeo y pesa 30 KB en vez de 101.
• play() se rechaza en pestañas en segundo plano. Quien abría la web en una pestaña nueva veía el vídeo congelado. Se arregló activando autoplay por JavaScript en el momento de enganchar.
• El aviso a IndexNow no llegó a tiempo en la primera ejecución. Esperó 15 minutos a que el dominio sirviera la web nueva y no envió nada. Se relanzó y funcionó.
• La caché DNS local guardó un «sin IPv4» durante el cambio y hubo que vaciarla para ver la web desde mi propio equipo.
• Decidí sin datos de Search Console. Las auditorías previas no sustituyen a las métricas reales, así que dejé abiertas las decisiones que dependían de ellas, como el slug definitivo de la página de reparación.

Lo que todavía no puedo afirmar es una mejora medida de tráfico, posiciones o llamadas: la web es reciente y aún no hay datos suficientes. Actualizaré este caso con Search Console y GA4 cuando haya historial, a los 60 o 90 días del lanzamiento.