Cómo encontré un <head> contaminado con ocho <title> y un home que servía otra página: el caso Vicent Florencia
¿Puede un sitio verse perfecto navegándolo y, al mismo tiempo, servir un HTML roto a cualquiera que no ejecute su JavaScript?
Por Pietro Fiorillo ·
Índice del artículo
El problema documentado: un portfolio personal que necesitaba verse profesional desde el primer clic
Vicent es bailarín y profesor de ballet clásico y danza contemporánea en Madrid. Necesitaba un sitio que transmitiera sensibilidad estética sin perder claridad comercial, con una sección «Sobre mí», servicios, galería y un canal de contacto directo para reservar clases.
Por qué decidí pedirle al sitio exactamente lo mismo que le pide un crawler
No tengo acceso al repositorio de este proyecto. En vez de limitarme a describir la arquitectura documentada, usé curl para pedir la home tal cual la pediría un buscador: sin ejecutar JavaScript, leyendo solo el HTML que el servidor devuelve de entrada.
Lo que encontré: un head con ocho títulos y un body que no corresponde
El <head> de https://vicentflorencia.com/ contiene ocho etiquetas <title> consecutivas: Contacto, FAQ, Vídeos, Galería, Servicios y Clases, Sobre Mí, el título completo del home, y un octavo genérico. No es una sola etiqueta con un texto largo: son ocho elementos <title> distintos, uno detrás de otro.
Más llamativo todavía: el <body> que sigue a ese head no es el de la home. Es, literalmente, el contenido de la página /contacto: el encabezado «Inicia el Movimiento», el bloque de contacto con WhatsApp e Instagram, y el formulario completo con sus campos de nombre, email y servicio de interés.
Repetí la solicitud en un momento distinto, por las dudas de que fuera un estado transitorio, y obtuve exactamente el mismo resultado las dos veces. No es un parpadeo pasajero: es lo que el servidor responde de forma consistente.
Por qué esto no se nota navegando el sitio
Es una SPA: apenas el JavaScript carga en el navegador, el router toma el control y muestra la página correcta según la URL, incluida la home real. Por eso una persona navegando el sitio nunca ve este problema. Quien sí lo ve es cualquier sistema que lea el HTML antes de ejecutar JavaScript, que es exactamente el caso de muchos crawlers y de la vista previa que arma una red social al compartir el link.
Resultados medibles
| Métrica | Resultado | Entorno / evidencia |
|---|---|---|
| Lighthouse Performance (móvil, lab) | 91 / 100 | Lighthouse 13.5.0, throttling simulado |
| LCP (lab) | 3,3 s | Misma medición Lighthouse, no es un dato de campo (CrUX) |
| Etiquetas <title> en la home | 8 | Confirmado dos veces con curl en momentos distintos |
| URLs en el sitemap | 12 | sitemap.xml público, confirmado con curl |
Un sitio que se ve perfecto no es lo mismo que un sitio que está bien. Lo primero lo juzga una persona navegando; lo segundo, cualquiera que lea el HTML tal cual llega.
Mi participación en este proyecto
Mi participación en Vicent Florencia incluyó el diseño de marca personal y el desarrollo del sitio, como parte de mi trabajo en MANYA Digital.
Lo que haría distinto: un bug de producción que no tenía forma de ver sin revisar el HTML crudo
Esto es, directamente, un defecto real en el sitio en producción, no una imprecisión en cómo lo documenté. No tengo acceso al repositorio ahora mismo para corregirlo, pero lo dejo documentado con la mayor precisión posible: la causa más probable, a partir de lo que puedo observar desde afuera, es un script de generación de HTML estático que no reinicia el <head> entre una ruta y la siguiente, y que en algún punto guardó el body equivocado para la home.
Qué probaría después
Si tuviera acceso al repositorio, mi primer paso sería revisar el script que genera el HTML estático de cada ruta, confirmar que reinicia el documento antes de procesar la siguiente página, y agregar una verificación automática simple (contar las etiquetas <title> de cada ruta publicada) para que un problema así se detecte en minutos y no en una revisión manual como esta.
Fuentes
Preguntas frecuentes
¿Qué significa que haya ocho etiquetas <title> en una sola página?
Que el head del documento acumuló el title de cada una de las ocho páginas del sitio, en vez de tener solo el que corresponde a esa URL. Es un síntoma de un proceso de generación de HTML que no reinicia el estado entre una página y la siguiente.
¿Esto afecta lo que ve una persona navegando el sitio?
Una vez que el JavaScript del sitio carga en el navegador, la aplicación toma el control y muestra la página correcta según la ruta. El problema es específico del HTML que se sirve antes de que el JavaScript corra, que es justamente lo que ven los crawlers y lo que determina el title que Google puede mostrar en los resultados.
¿Por qué el body que se sirve en la home es el de la página de contacto?
No tengo acceso al repositorio para confirmar la causa exacta, pero el patrón es consistente con un script de prerenderizado que visita cada ruta y guarda el HTML resultante, y en algún punto el archivo de la home terminó sobrescrito con el contenido de la última ruta visitada en vez de la correspondiente.
¿Es un caso aislado o lo viste en otros proyectos?
En esta misma serie documenté un problema distinto de prerenderizado (ausente, no corrupto) en otro proyecto, y until confirmé que funciona correctamente en un tercero. Cada caso tiene una causa distinta; lo que comparten es que ninguno se nota navegando el sitio a simple vista.
¿Cómo verificaste esto sin acceso al código?
Pedí la home con curl dos veces, en momentos distintos, y obtuve el mismo resultado las dos veces: ocho <title>, un body con el formulario de contacto. No es un error de mi herramienta, es lo que el servidor responde de forma consistente.
¿Cómo se arreglaría esto?
Revisando el script de generación de HTML estático para confirmar que reinicia el head (y guarda el body correcto) antes de procesar cada ruta nueva. Sin acceso al repositorio, no puedo decir más que eso.