Cómo verifiqué, sin acceso al código, que el prerenderizado de un sitio había dejado de funcionar: el caso AV Automotores
¿Se puede verificar con confianza una afirmación técnica sobre un sitio sin tener acceso a su código?
Por Pietro Fiorillo ·
Índice del artículo
El problema documentado: un catálogo que cambia todo el tiempo
El catálogo de AV Automotores cambia constantemente: entran y salen vehículos, cambian precios, se suman fotos. La arquitectura documentada para este proyecto es una SPA en React y Vite con un script de prerenderizado que genera HTML propio por ruta, para que los crawlers reciban contenido ya armado sin depender de JavaScript.
Por qué decidí verificarlo de nuevo en vez de darlo por hecho
Escribiendo esta serie de artículos, decidí no limitarme a repetir lo que ya estaba documentado sobre cada proyecto. Para este, no tengo acceso al repositorio actual, así que la única verificación posible era pedirle al sitio en producción exactamente lo que le pediría un crawler, y mirar qué contesta.
Cómo verifiqué el sitio en producción, sin acceso al repositorio
Tomé una muestra de URLs reales del sitemap.xml público del sitio: la home, /catalogo y dos fichas de vehículo (gilera-vc-150-full-disco-disco y otra). Pedí cada una con curl -sL (siguiendo redirecciones) y comparé el HTML completo que devolvía cada una.
Las cuatro respuestas fueron, carácter por carácter, el mismo documento: el mismo <title>AV MOTOS | Financiación de Motos en Argentina</title>, la misma meta description, y un <link rel="canonical" href="https://avmotos.com/"> que no cambia sin importar qué ruta se pida. No encontré ningún bloque <script type="application/ld+json"> en ninguna de las cuatro.
| Elemento | Documentado | Observado en producción |
|---|---|---|
| Title y canonical por ruta | Prerenderizado, uno por vehículo | El mismo en las 4 rutas probadas, canonical siempre al home |
| Datos estructurados Schema.org | Vehicle, Organization, Breadcrumb, FAQ | Ninguno encontrado en el HTML servido |
| Sitemap.xml | Generado desde Firestore | 171 URLs reales, confirmado |
| Headers de seguridad | CSP y headers estrictos | CSP, HSTS, X-Content-Type-Options y X-Frame-Options confirmados |
Resultados medibles
| Métrica | Resultado | Entorno / evidencia |
|---|---|---|
| Lighthouse Performance (móvil, lab) | 46 / 100 | Lighthouse 13.5.0, throttling simulado |
| LCP (lab) | 6,4 s | Misma medición Lighthouse, no es un dato de campo (CrUX) |
| URLs en el sitemap | 171 | sitemap.xml público, confirmado con curl |
| Rutas con HTML idéntico | 4 de 4 probadas | Home, catálogo y 2 fichas de vehículo |
Un <link rel="canonical"> que siempre apunta al home, sin importar la ruta, le dice a Google que todas esas páginas son la misma. Para un catálogo que vive de que cada vehículo se indexe y aparezca por su propia búsqueda, es un problema real, no cosmético.
Verificar lo que un sitio sirve de verdad, sin ejecutar JavaScript, es la forma más honesta de saber qué ve un buscador.
Mi participación en este proyecto
Mi participación en AV Automotores incluyó el desarrollo de la SPA, la integración con Firestore y el diseño original de la estrategia de SEO técnico, como parte de mi trabajo en MANYA Digital.
Lo que haría distinto: una afirmación pública que la producción no sostiene hoy
La página de este proyecto en mi sitio describía un prerenderizado por ruta y datos estructurados Schema.org funcionando. La verificación en vivo no lo sostiene. Ya corregí esa página para reflejar lo que observé, en vez de dejar una afirmación que no puedo confirmar con el sitio real.
Qué probaría después
Volvería al repositorio (si tuviera acceso) para confirmar si el script de prerenderizado sigue en el código y corriendo en el build, o si una regla de rewrite del hosting está sirviendo el shell de la SPA para toda ruta sin distinción. También agregaría una verificación automática simple, como comparar el <title> de dos rutas distintas después de cada deploy, para detectar una regresión así antes de que pase meses sin notarse.
Fuentes
Preguntas frecuentes
¿Por qué todas las páginas muestran el mismo title y la misma descripción?
Porque, al momento de revisar el sitio el 18 de octubre de 2026, cada ruta devolvía el mismo HTML genérico de la SPA, sin que un paso de prerenderizado por ruta se ejecutara. Es lo que vi desde afuera; no tengo acceso al repositorio para saber por qué.
¿Esto afecta el SEO real del sitio?
Un crawler que no ejecuta JavaScript vería el mismo title, la misma descripción y el mismo canonical (apuntando al home) en cada vehículo. Eso es, como mínimo, una señal de contenido duplicado y fichas de producto sin diferenciar para buscadores que no rendericen JavaScript.
¿Por qué no corregiste el repositorio en este artículo?
Porque no tengo acceso a él. Actualicé la página de este proyecto en mi sitio para reflejar lo que observé en producción, pero la corrección del propio sitio de AV Automotores depende de volver a ese código, que no es el que estoy documentando acá.
¿Los headers de seguridad que menciona el proyecto son reales?
Sí. Verifiqué con curl que el sitio responde con Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options y X-Frame-Options configurados correctamente. Esa parte del proyecto se sostiene.
¿El sitemap está bien?
Sí. Tiene 171 URLs reales, sincronizadas con el catálogo. El problema que encontré es específico del HTML que se sirve en cada una de esas URLs, no del sitemap en sí.
¿Cómo solucionarías esto?
Volvería al repositorio para confirmar si el script de prerenderizado sigue existiendo y corriendo en cada build, o si una regla de rewrite del hosting está sirviendo el shell de la SPA para todas las rutas en vez del HTML prerenderizado. Sin ver el código, no puedo decir cuál de las dos es.