Meta Description Updated by JavaScript: How to Fix It

What this issue means

This flag means the meta description in your page's raw HTML is not the same as the meta description in the rendered HTML. The page loads with one value in the source code, and then a script rewrites the <meta name="description"> tag in the browser, leaving a different value once JavaScript has finished executing.

There are two related situations a crawler reports. One is a description that exists only in the rendered HTML, where the raw source has none at all. The other, the one flagged here, is a description that exists in the raw HTML but gets updated by JavaScript to a different string. Both create a mismatch between what a search engine sees on its first pass and what it sees after rendering, and that gap is the root of the problem.

Why JavaScript-set meta descriptions are risky

Google processes pages in two waves. In the first wave it crawls and reads the raw HTML, where it immediately evaluates signals such as the title, meta description, canonical, and robots tags. In the second wave a separate service renders the page with a headless browser and runs your JavaScript. The description your script sets only becomes visible to Google in that second wave.

The trouble is that the second wave is deferred and not guaranteed on any fixed schedule. The delay between crawling and rendering is variable, and rendering competes for a finite render budget. Google has stated the gap can range from moments to days or longer when the rendering queue is busy. Until rendering happens, the only description Google holds for your page is the raw-HTML one your script intends to replace. That can mean a stale or placeholder description shown in search results, or a mismatch that makes your intent ambiguous to the crawler.

How Google renders the page

Google can in fact use a JavaScript-set meta description, and its own guidance confirms you are technically allowed to set or change the description with JavaScript. But "can use" is not "will use immediately." The rendered value is only adopted once the Web Rendering Service has rendered the URL, which is a queued, best-effort step. Other crawlers, social platforms, and many third-party tools never render JavaScript at all and will only ever read the raw HTML. So the value your script writes is invisible to a meaningful share of the systems that consume your meta description.

How to diagnose it

Confirm the mismatch with three quick checks:

View source. Open view-source: on the URL in your browser and find the <meta name="description"> tag. This is the raw HTML, before any JavaScript runs.

Inspect the rendered DOM. Open DevTools, go to the Elements panel, and find the same tag. This reflects the page after scripts have executed. If the two strings differ, you have reproduced the issue.

Use the URL Inspection tool in Google Search Central's Search Console. Run a live test and view the rendered HTML and screenshot to see exactly what Google's renderer produces. In a crawler such as Screaming Frog or Sitebulb, enable JavaScript rendering (in Screaming Frog, Config then Spider then Rendering, set to JavaScript) so the crawler stores both the raw and rendered HTML and reports the difference as a parity issue.

How to fix it

The fix is to make the raw HTML and the rendered HTML agree by setting the final meta description server-side, so the correct value is present on the first crawl wave with no rendering required.

If a template or CMS field generates the description, set it there and remove the client-side script that overwrites it. The tag your server returns should already be the final one:

<!-- Final value, present in the raw HTML -->
<meta name="description"
      content="The exact description you want Google to use.">

If the description depends on data only your JavaScript framework has, render it on the server or at build time rather than in the browser. Frameworks expose head-management for exactly this, and the goal is for the value to land in the document the server sends, not to be patched afterward:

// Server-side / build-time head injection (concept)
// Resolve the description on the server, emit it in HTML.
res.send(renderPage({
  description: buildDescription(pageData) // computed server-side
}));
// Result: the <meta> tag is correct in the response body,
// not rewritten by a later client script.

After deploying, re-run view-source and confirm the raw HTML now carries the final description, then request indexing in Search Console so the corrected value is picked up.

Common mistakes

Leaving a placeholder in the source. Shipping a generic or empty description in the raw HTML and trusting a script to replace it means crawlers that do not render, and Google before its render pass, see the placeholder.

Patching the tag client-side after measuring the problem. Adding more JavaScript to "correct" the description keeps you dependent on the deferred render wave. The value must be in the server response.

Assuming the rendered value always wins. It only wins once rendering happens, and only for systems that render at all. Treat the raw HTML as the source of truth.

Fixing one template and forgetting the rest. If a plugin or shared layout injects descriptions site-wide, the same mismatch likely repeats across many URLs. Re-crawl with rendering enabled to confirm coverage.

FAQ