Prerendered Nuxt 4 blog pages refetched their articles from Storyblok on every browser visit

The site is a static Nuxt 4 build with Storyblok as the CMS ^[2]. Its article page loaded data with a top-level `await` inside `<script setup>` ^[5]. That code runs during prerendering, so the generated HTML is complete ^[5]. It runs again in the browser when the page hydrates, and nothing tells Nuxt the data already exists ^[5]. According to the developer's write-up, `useAsyncData` and `useFetch` store their result in the page payload, and a bare `await` does not ^[5]. The `spaces/me` request came from the service fetching Storyblok's cache version before it asked for the story ^[6].

The error handling made the extra request risky. The `catch` threw a fatal 404, so a rate limit, a flaky network or a blocked request in the browser replaced a good prerendered article with the error page ^[7]. The developer's theory starts there. Googlebot renders JavaScript, often for many URLs in a row, and if the CMS call fails during those renders, every affected URL shows the same error screen ^[8]. Identical content on several URLs is what Google clusters as duplicates, with one canonical picked for the group ^[8].

"To be honest, I can't prove that's what happened here," the developer wrote ^[9]. The live test renders fine today, and older posts running the same code did get indexed ^[10]. The Network tab found a real defect after the other checks had passed ^[3][4], but the evidence stops short of tying that defect to the canonical folding ^[9][10].

The fix is small, and I think it is the right one. The fetch moved into `useAsyncData`, keyed as `blog-article-${locale}-${slug}` ^[11]. During `nuxt generate`, the handler runs once and its result is written to `/blog/<slug>/_payload.json` ^[11]. On hydration, and on client-side navigation to a prerendered route, Nuxt reads that file and does not run the handler again ^[11]. The service now returns `null` instead of throwing, so the 404 fires only when the story did not exist at build time ^[12]. Project pages had the same pattern and got the same fix ^[14].

The payload needed its own trim. Eight articles went out for every related-article card the page showed ^[18]. The new code computes reading time from each body, then sets `content` to null, because cards need only title, excerpt, cover and tags ^[17]. The post does not give the payload size after the change.

Two conditions have to hold for the same bug to exist on another site. Pages are prerendered, and data is loaded with a bare `await` instead of `useAsyncData` or `useFetch` ^[5]. The fix then adds a requirement of its own: the key has to be identical on server and browser and unique per page ^[13]. On this site, putting both locale and slug in the key satisfies that ^[11][13].