Old AJAX Crawling Meta Fragment: How to Remove It Safely
- April 6, 2025
- Indexation, JavaScript
This check fires when a page still carries <meta name="fragment" content="!"> — the flag that opted a site into Google's old AJAX crawling scheme. That scheme is dead. Google deprecated it in 2015 and stopped supporting it entirely a few years later, moving to rendering JavaScript directly. Leaving the meta fragment tag in place tells crawlers to expect a special pre-rendered snapshot workflow that no longer exists, which at best is dead weight and at worst points bots at a rendering path you've long since removed.
This page is about the tag. Its sibling covers the #! and ?_escaped_fragment_= URL scheme that the tag used to trigger. Same dead standard, two different fingerprints — this one is the head-level opt-in, that one is the URL machinery.
What the tag used to do
Back when crawlers couldn't execute JavaScript, the AJAX crawling scheme let a site say "I'm a JS app, come get a pre-rendered version." A hashbang URL like example.com/#!/page plus this meta tag on non-hash URLs signaled Google to request an ?_escaped_fragment_= version that your server rendered to flat HTML. Google would index that snapshot instead of the JS page.
Google now renders JavaScript in Googlebot directly. The escaped-fragment handshake is gone. Here's the stale opt-in still sitting in a head:
<!DOCTYPE html>
<html>
<head>
<meta name="fragment" content="!"> <!-- DEPRECATED: signals a dead scheme -->
<title>Product Catalog</title>
</head>If your escaped-fragment endpoint still exists, you're maintaining a snapshot pipeline nobody reads. If it's been torn down, this tag advertises a workflow that 404s or serves stale HTML.
The fix: delete the tag, render properly
<!DOCTYPE html>
<html>
<head>
<!-- meta fragment removed -->
<title>Product Catalog</title>
</head>Removing the tag is one line. The real work is making sure the page's content is available to crawlers without it — via server-side rendering, static generation, or dynamic rendering as a stopgap. If the tag was the only thing making your JS app crawlable, don't just delete it and walk away; confirm the rendered HTML actually contains your content first.
Then vs. now
| Aspect | AJAX crawling scheme (pre-2015) | Modern crawling (now) |
|---|---|---|
| Opt-in signal | <meta name="fragment" content="!"> | None needed |
| How Google gets content | Requests _escaped_fragment_ snapshot | Renders the JS directly |
| Your obligation | Maintain a pre-render endpoint | Ship crawlable HTML (SSR/SSG) |
| Status of the tag today | — | Ignored / dead weight |
| Risk of leaving it | — | Confusion, stale pipeline, wasted maintenance |
How to detect it
- Screaming Frog. Use Custom Search (Config → Custom → Search) and add a filter for
name="fragment". Crawl, then open the Custom Search tab to list every URL still carrying the tag. For a JS-heavy site, enable JavaScript rendering so Frog sees the head as Google would. - View Source. Ctrl+U on a page and Ctrl+F for
fragment. The tag lives in the head, so it's easy to spot in the raw source. Check a template-level page and a few deep pages — if it's coming from a shared layout, it'll be on everything. - Google Search Console. URL Inspection → View crawled page shows the rendered HTML. Confirm the meta fragment is still present and, more importantly, confirm your actual content renders without relying on the old snapshot path. If the rendered HTML is thin, the JS isn't rendering and removing the tag alone won't save you.
How to fix it
- Verify content renders without the scheme. Before touching anything, inspect the rendered HTML in GSC or Frog's rendered view. If your content is there, you're safe to remove the tag. If it isn't, fix rendering first.
- Remove
<meta name="fragment" content="!">from the template so it's gone site-wide. - Adopt real rendering. Move to server-side rendering or static generation so crawlers get complete HTML. Prerendering works as a bridge if you can't refactor immediately.
- Retire the escaped-fragment endpoint once nothing depends on it, and clean up any related URL scheme — see the escaped_fragment scheme check.
- Re-render and confirm in GSC that content is intact and the tag is gone.
FAQ
Does the meta fragment tag actively harm my SEO?
It won't get you penalised, but it advertises a dead workflow and often correlates with a fragile rendering setup. The danger is what it implies about how your JS is served, not the tag itself.
Can I just delete it and be done?
Only if your content already renders in crawlable HTML without the old snapshot path. Delete-and-verify, not delete-and-hope. Check the rendered HTML first.
How is this different from the escaped_fragment scheme check?
This one flags the head-level opt-in tag. The other check flags the #! hashbang URLs and ?_escaped_fragment_= request handling. They're two halves of the same obsolete mechanism.
What should replace the AJAX crawling scheme?
Direct rendering. Ship server-side or static HTML so Googlebot reads your content on the first pass. For the full rationale, see SSR vs CSR and the JavaScript SEO rendering guide.
Do AI crawlers care about this too?
Yes, and more so — many AI crawlers execute little or no JavaScript, so a page that leaned on the old scheme is often invisible to them. Real server-rendered HTML is the safe path for both Google and AI bots.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
