Free Check for noindex, nosnippet and data-nosnippet

This check answers one question: is your own markup or server telling Google and Bing to keep a page, or part of it, out of AI answers?

Google states that a page must be "indexed and eligible to be shown in Google Search with a snippet" to appear as a supporting link in AI Overviews or AI Mode. That makes four directives decisive on Google surfaces:

• noindex removes the page from the index, so it can't be a supporting link. See how noindex works.
• nosnippet removes snippet eligibility for the whole page. See what nosnippet does to AI features.
• max-snippet:0 has the same effect as nosnippet. A small positive number limits how much text can be shown.
• data-nosnippet on an HTML element hides that element's text from snippets.

On Bing, as of its October 2025 announcement, content marked data-nosnippet "is still indexed normally, but it will be excluded from snippets and AI summaries." Bing adds that the tagged content remains available for ranking.

These are subtractive controls. They can only take content out. If you find none, the result means nothing is blocked here, not that you will be cited.

You need a terminal and a browser. Replace the example URL with one page from each template you run (home, product, blog post, pricing).

1. Read the response headers. Look for an X-Robots-Tag header.

curl -sI https://example.com/pricing | grep -i x-robots-tag

No output means no header. Any output containing noindex, nosnippet or max-snippet applies to the whole URL, including PDFs and images. The X-Robots-Tag playbook covers checking every template.

2. Read the raw HTML for robots meta tags. Fetch the page without running JavaScript.

curl -s https://example.com/pricing | grep -iE 'name="(robots|googlebot|bingbot)"'

Check the generic robots tag and the bot-specific ones. A googlebot tag applies only to Google.

3. Search for data-nosnippet. Count and locate every instance.

curl -s https://example.com/pricing | grep -o '<[^>]*data-nosnippet[^>]*>'

For each hit, open view-source in your browser and note which element carries it and how much content sits inside.

4. Compare raw HTML with the rendered page. Open DevTools, inspect the rendered DOM, and search for robots and data-nosnippet. If a directive appears only after JavaScript runs, crawlers that don't render won't see it. Read whether AI crawlers see JavaScript-added robots tags.

5. Record the result per template. One row per template: header value, meta value, data-nosnippet count, and whether each was intended.

Each directive has a different scope. The table shows what each does to AI answer display, based on Google's robots meta tag documentation and Bing's data-nosnippet announcement.

Then ask one question of every hit: did someone mean this? A data-nosnippet on a legal disclaimer may be deliberate. A nosnippet on your pricing page almost never is. The noindex vs nosnippet vs data-nosnippet comparison walks through when each is the right tool.

The failure this check most often catches is a directive meant for one element that ended up in a shared template.

How it happens:

• Someone adds data-nosnippet to hide a cookie banner, but puts it on a wrapper div that also contains the main content.
• A developer adds nosnippet to the layout's head section while testing, and it ships to every page.
• A server rule sets X-Robots-Tag: noindex for PDFs or a staging host, but the pattern matches the live site too.
• A CMS setting meant for archive pages applies noindex to all posts.

None of these trigger a warning. The page loads normally for visitors. It just stops being eligible for AI answers on Google, or its key text disappears from Bing AI summaries.

The fix is to move the directive to the narrowest scope that does the job: the single element, the single URL pattern, or the single environment. Then re-run step 1 to 3 on every template. For a fuller sweep, follow the accidental noindex audit.

A clean result rules out on-page suppression. It doesn't confirm visibility. Several gates sit outside your HTML and headers:

• Actual index membership. Markup shows eligibility signals, not whether Google or Bing holds the page. Run a free index status check for Google and Bing for that.
• The Search Console generative AI control. Google treats inclusion in AI Overviews, AI Mode and Discover generative features as opt-out, with inclusion as the default. A property can still be opted out, and child properties inherit the parent's setting. No crawl can see this, so check the setting in Search Console directly.
• robots.txt. There is no robots.txt token that blocks AI Overviews or AI Mode. Googlebot rules are the control there.
• Firewalls and CDNs. A crawler that gets a 403 never reads your meta tags at all.
• Selection. Being eligible doesn't mean being chosen. Google states that indexing and serving isn't guaranteed. Nobody outside the engine controls which eligible pages get used.

The engines' own free tools confirm what they saw, which curl can't.

• Google Search Console URL Inspection. It reports whether indexing is allowed for a URL and shows the crawled page, including directives Google detected after rendering.
• Bing Webmaster Tools URL Inspection. It shows how Bing sees a URL. The same account also holds Bing's AI Performance report on Copilot citations.
• Browser DevTools. The Network tab shows response headers, including X-Robots-Tag, for any request without a terminal.

Use curl for a fast sweep across templates, then confirm suspicious pages in Search Console and Bing Webmaster Tools. If both report the page as indexable with no snippet restriction, on-page suppression is not your problem, and the next places to look are crawler access and index status.