Caso de éxito · Romanketing
Romanketing — reconstrucción del sitio y rescate del dominio
De un HTML vacío que ningún rastreador podía leer a 15 rutas con contenido, metadatos y datos estructurados propios
El cliente
Este es nuestro propio sitio, y lo publicamos por la misma razón por la que pedimos acceso a los datos de un cliente antes de proponer: es el caso que podemos documentar por completo, con cada verificación reproducible por cualquiera con una terminal.
El reto
El dominio venía de una instalación de WordPress abandonada. Quedaban URLs viejas indexadas y el sitio nuevo, hecho como aplicación de una sola página, entregaba un HTML vacío: los buscadores que no ejecutan JavaScript no veían ni el título principal ni un solo enlace interno. Una auditoría técnica lo reportó como ausencia de H1 y ausencia de enlaces entrantes en las 13 páginas de entonces.
Los objetivos
- Servir el contenido completo en el HTML inicial, sin depender de JavaScript.
- Dar a cada ruta sus propios metadatos, canonical y datos estructurados.
- Sacar del índice el rastro del WordPress anterior sin romper nada del sitio nuevo.
- Dejar el sitemap regenerándose solo en cada publicación, para que ninguna página nueva quede fuera.
Qué se hizo, disciplina por disciplina
Desafío inicial
La aplicación dibujaba todo el contenido en el navegador. Un rastreador sin JavaScript recibía un contenedor vacío: sin encabezado principal y sin enlaces internos que seguir.
Estrategias implementadas
- Prerenderizado estático real —no renderizado condicional por user-agent—: todo el mundo recibe el mismo HTML completo.
- Un archivo HTML por ruta, con el marcado de la página ya resuelto dentro del contenedor de montaje.
- Render determinista para que el HTML del servidor y el primer render del navegador coincidan y la hidratación no rompa.
Desafío inicial
Todas las rutas compartían el mismo título y la misma descripción, y el único bloque de datos estructurados era genérico para todo el sitio.
Estrategias implementadas
- Título, descripción, Open Graph, Twitter y canonical resueltos por ruta desde una única fuente de verdad.
- JSON-LD por página: Organization, LocalBusiness, ProfessionalService, BreadcrumbList, Service y FAQPage.
- Verificación automatizada en el build, que falla si aparece un título o una descripción repetidos.
Desafío inicial
El catch-all del hosting respondía 200 a las rutas viejas del WordPress, así que seguían indexadas aunque el contenido ya no existiera.
Estrategias implementadas
- Cabecera X-Robots-Tag noindex, follow sobre las rutas remanentes: autor, feeds, comentarios, papelera y rutas de WordPress.
- Bloqueo de la URL de búsqueda con query string en robots.txt, que no se puede marcar por cabecera.
- Decisión explícita de no bloquear en robots.txt las rutas marcadas con noindex: si Google no puede leerlas, no puede aplicar la directiva.
Resultados
Las cifras de este proyecto todavía no están autorizadas para publicación. Preferimos dejar el espacio vacío antes que llenarlo con números que no podemos respaldar: cuando el cliente autorice los datos de sus propias herramientas, aparecen acá con su fuente y su periodo.
Cómo lo medimos
La verificación no depende de una herramienta de pago: se hace con dos comandos por URL, pidiendo la página con el agente de usuario de Googlebot y comprobando que el HTML devuelto contiene el encabezado principal y más de diez enlaces internos. El criterio de aceptación se aplica a las 15 URLs del sitemap, y se vuelve a correr después de cada publicación.
Conclusión
El caso muestra el orden en que conviene resolver un sitio: primero que el contenido llegue, después que cada página diga qué es, y recién entonces contenido y autoridad. Invertir ese orden es publicar sobre una base que no puede sostener el trabajo. Es también el punto de partida de nuestro servicio de GEO: sin HTML legible y sin datos estructurados no hay motor de IA que pueda citar a nadie.
