How to audit JavaScript rendering issues for technical SEO on UK news sites

What to take away

Why React and Vue news templates break first

A newsroom publishes hundreds of URLs a day, often through a single template. React and Vue sites ship a small HTML shell and fetch headlines later, so the first crawl can return an empty container. JavaScript runs in the browser, and a crawler has to do more work to reach the same content.

For UK examples, compare public article, section and archive page types on BBC News, The Guardian, The Telegraph and MailOnline; do not infer their rendering setup from appearance.

Googlebot crawls the HTML soon after publication and renders later. On a breaking story, that gap decides whether your article is eligible for Top Stories while the topic is live.

How Googlebot renders and what it reports

Rendering is a queued second stage of crawling, not part of the first fetch. Googlebot reads the raw response, then a renderer executes scripts and stores the result for indexing. Google Search Console is where both views sit: URL Inspection shows the rendered HTML and the resources that failed to load.

Crawl Stats in the same tool reports how many render requests Google made and the response codes it received. A rise in 5xx codes during rendering points at your application server rather than the CDN.

Comparing rendering approaches

Four routes are in common use, and each trades build effort against freshness.

Treat dynamic rendering as a stopgap. It adds a second build path to maintain and test, which is awkward for a newsroom shipping template changes weekly.

Audit steps that find the break

Google's documentation on consolidating duplicate URLs sets out how rel=canonical behaves, which matters when a script injects the tag after load.

Keep a before-and-after record of the rendered HTML. It is the only evidence that a fix worked when someone asks why rankings moved.

Test the response, not the browser

Fetch pages with curl using a plain user agent and save the output. Then load the same URL in a browser with JavaScript disabled and compare the two files.

If the raw HTML contains the headline but the rendered DOM does not, the problem sits in hydration. If neither contains it, the data is arriving through a separate API call the crawler never triggers.

CDN purge tools and your framework's build output show whether the empty shell came from the edge or the application. Check that before rewriting components.

UK hosting, CDN and consent quirks

Edge caches at UK points of presence can keep serving a stale pre-render after a template deploy. Cloudflare, Fastly and Akamai are examples of CDN/edge providers that can serve UK traffic; check your own DNS, response headers and hosting configuration rather than assuming which provider a site uses. Purge the cache as part of the release, not the morning after.

Consent management platforms such as OneTrust, Didomi, Sourcepoint and Usercentrics can hold back scripts until a visitor makes a choice. Check the implementation against ICO guidance and the requirements of PECR and UK GDPR. If headlines load only after a consent choice, a first visit may return a shell; keep editorial content outside the consent gate and load analytics separately.

Measure the change at scale by exporting Search Console bulk data, which lets you compare indexed counts across thousands of article URLs before and after a rendering fix.

Common questions

Does dynamic rendering still work?

It still functions, and user-agent detection remains the mechanism. Treat it as temporary: it splits your codebase and makes testing slower.

How long does reindexing take after a rendering fix?

High-demand stories tend to be recrawled quickly. Archive pages wait longer, so watch Crawl Stats and URL Inspection rather than assuming a fixed timetable.

Do I need to pre-render every article?

No. Pre-render section pages, tag archives and paginated lists. Article templates are better served by server-side rendering, so the headline arrives in the first byte of HTML.