How I verified, with no code access, that a site's prerendering had stopped working: the AV Automotores case
Can you reliably verify a technical claim about a site without access to its code?
By Pietro Fiorillo ·
In this article
The documented problem: a catalog that changes constantly
AV Automotores' catalog changes constantly: vehicles come and go, prices change, photos are added. The documented architecture for this project is a React and Vite SPA with a prerender script that generates its own HTML per route, so crawlers get ready-made content without depending on JavaScript.
Why I decided to re-verify it instead of taking it for granted
Writing this series of articles, I decided not to just repeat what was already documented about each project. For this one, I don't have access to the current repository, so the only verification possible was asking the production site exactly what a crawler would ask it, and looking at what it answers.
How I verified the production site, with no repository access
I took a sample of real URLs from the site's public sitemap.xml: the homepage, /catalogo, and two vehicle pages (gilera-vc-150-full-disco-disco and another). I requested each with curl -sL (following redirects) and compared the full HTML each one returned.
All four responses were, character for character, the same document: the same <title>AV MOTOS | Financiación de Motos en Argentina</title>, the same meta description, and a <link rel="canonical" href="https://avmotos.com/"> that doesn't change no matter which route is requested. I found no <script type="application/ld+json"> block on any of the four.
| Element | Documented | Observed in production |
|---|---|---|
| Title and canonical per route | Prerendered, one per vehicle | The same on all 4 routes tested, canonical always to the homepage |
| Schema.org structured data | Vehicle, Organization, Breadcrumb, FAQ | None found in the served HTML |
| Sitemap.xml | Generated from Firestore | 171 real URLs, confirmed |
| Security headers | CSP and strict headers | CSP, HSTS, X-Content-Type-Options and X-Frame-Options confirmed |
Measurable results
| Metric | Result | Environment / evidence |
|---|---|---|
| Lighthouse Performance (mobile, lab) | 46 / 100 | Lighthouse 13.5.0, simulated throttling |
| LCP (lab) | 6.4 s | Same Lighthouse run, not field (CrUX) data |
| URLs in the sitemap | 171 | Public sitemap.xml, confirmed with curl |
| Routes with identical HTML | 4 of 4 tested | Homepage, catalog and 2 vehicle pages |
A <link rel="canonical"> that always points to the homepage, no matter the route, tells Google that all those pages are the same one. For a catalog that depends on each vehicle getting indexed and showing up for its own search, that's a real problem, not a cosmetic one.
Checking what a site actually serves, without executing JavaScript, is the most honest way to know what a search engine sees.
My part in this project
My part in AV Automotores included building the SPA, integrating it with Firestore and the original technical SEO strategy design, as part of my work at MANYA Digital.
What I'd do differently: a public claim production doesn't support today
This project's page on my site described working per-route prerendering and Schema.org structured data. The live check doesn't support that. I've already corrected that page to reflect what I observed, instead of leaving a claim I can't confirm against the real site.
What I'd test next
I'd go back to the repository (if I had access) to confirm whether the prerender script is still in the code and running at build time, or whether a hosting rewrite rule is serving the SPA shell for every route with no distinction. I'd also add a simple automated check, like comparing the <title> of two different routes after every deploy, to catch a regression like this before months go by unnoticed.
Sources
Frequently asked questions
Why do all pages show the same title and description?
Because, when I checked the site on October 18, 2026, every route returned the same generic SPA HTML, with no per-route prerender step running. That's what I saw from the outside; I don't have repository access to know why.
Does this affect the site's real SEO?
A crawler that doesn't execute JavaScript would see the same title, the same description and the same canonical (pointing to the homepage) on every vehicle. That's, at minimum, a duplicate content signal and undifferentiated product pages for search engines that don't render JavaScript.
Why didn't you fix the repository in this article?
Because I don't have access to it. I updated this project's page on my site to reflect what I observed in production, but fixing AV Automotores' own site depends on going back to that code, which isn't what I'm documenting here.
Are the security headers the project mentions real?
Yes. I verified with curl that the site responds with Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options and X-Frame-Options correctly configured. That part of the project holds up.
Is the sitemap fine?
Yes. It has 171 real URLs, synced with the catalog. The problem I found is specific to the HTML served at each of those URLs, not the sitemap itself.
How would you fix this?
I'd go back to the repository to confirm whether the prerender script still exists and runs on every build, or whether a hosting rewrite rule is serving the SPA shell for every route instead of the prerendered HTML. Without seeing the code, I can't say which of the two it is.