It is a working average, not a limit. Someone measured a batch of results, found the cut usually landed near 155 characters, and the number spread because it is easy to remember. What Google actually does is render the description in a specific font at a specific size inside a container of a specific width, then drop whatever does not fit.

The practical consequence: character count and rendered width disagree constantly. A description of 150 narrow characters fits. A description of 138 characters with several capital M and W does not. If you have ever shipped a snippet that looked correct in your CMS and appeared chopped in search, this is why.

The two widths that matter

Desktop results render the description at roughly 14px in a container around 600px wide. Mobile is narrower — meaningfully narrower, not marginally. A description tuned exactly to the desktop limit will be cut on a phone, and most of your traffic is on a phone.

The safe approach is to aim at the mobile limit, not the desktop one. Put the part that must survive in the first 120 characters and treat everything after that as optional elaboration.

When Google ignores your description entirely

Often. If Google decides a sentence from your page body matches the query better than the description you wrote, it substitutes that sentence. This is normal behaviour and not a signal that anything is wrong.

You cannot force it to use your text. What you can do is remove the reason to substitute: write the opening sentence of the page so that it would work as a snippet on its own, and keep the meta description aligned with what the page actually says. When the two agree, there is nothing to gain by swapping.

What is not worth doing

Do not stuff the description with keyword variants. Descriptions are not a ranking factor; their entire job is to earn the click. A description written for a machine reads like it was written for a machine, and gets skipped.

Do not write one description and reuse it across a template. Duplicate descriptions are not penalised, but they make every page in a set look identical in the results, which costs you the clicks that a specific sentence would have earned.

A working method

Draft the description last, after the page is written. At that point you know what the page actually delivers, and you can say it in one sentence without guessing. Descriptions written before the page exists tend to describe the page you intended rather than the one you shipped.

Then put the sentence into a preview and check where it lands. If the important part is past the mobile cut, move it forward rather than trimming the tail — the end of a description is the cheapest thing to lose.

One more thing worth doing: read the first sentence of the page body next to the description. If they are far apart, Google has a reason to substitute one for the other. Aligning them is the closest thing to control you have over what gets shown.

This is the most damaging one and it looks reasonable. You want a page out of the index, so you add noindex — and you also disallow it so crawlers stop wasting time. But a crawler that cannot fetch the page can never read the noindex. The URL stays in the index indefinitely, usually with a note saying it was not crawled.

The fix is counterintuitive: to remove a page using noindex, you must allow crawling. Let Google fetch it, see the directive, and drop it. Only then disallow, if you still want to.

2. Blocking CSS and JavaScript

An older habit, and still common in older configs. Google renders pages, and rendering requires your stylesheets and scripts. Block /assets/ or /static/ and Google sees a page with no layout, which it may judge as broken or as a poor mobile experience.

Check your file for broad disallows on asset directories. If they exist, remove them — there is no upside to blocking Google from seeing your own stylesheet.

3. Assuming order decides priority

It does not. Within a user-agent group, the longest matching path wins regardless of line order. So Disallow: /admin/ followed by Allow: /admin/public/ leaves /admin/public/ crawlable. Reordering those lines changes nothing, which is why people conclude the file is being ignored when it is behaving exactly as specified.

4. Wildcard patterns that over-match

Disallow: /*.pdf$ blocks PDFs — and if written slightly wrong, blocks far more. A misplaced * or a missing $ turns a narrow rule into a site-wide block. Because robots.txt produces no warnings, this can run for months before anyone notices the traffic drop.

Test every rule containing a wildcard against a few real URLs before deploying it. That is what the tester on this site is for.

5. Forgetting that staging is one typo away from public

A staging host protected by robots.txt alone is not protected. Any crawler that ignores the file — and there are many — will index it. Duplicate staging content competing with production is a slow, confusing problem to untangle later.

Put real authentication in front of staging. Keep the robots.txt disallow as well, but understand it is politeness, not a lock.

A five-minute check that catches all of these

Fetch your robots.txt and paste it into a tester. Then run five URLs through it: your homepage, a category page, a deep article, one asset from your stylesheet directory, and a URL you believe is blocked. If any of the five gives a verdict you did not expect, you have found the bug — and you have found it before Google did.

Do this again after any deploy that touches routing, and any time someone new edits the file. The failure mode here is silence: nothing breaks visibly, nothing appears in an error log, and traffic from one section of the site quietly stops arriving. A monthly five-minute check is the entire maintenance cost.

Headings create a navigable outline. A screen reader user can jump between headings to understand a page without reading it linearly; a sighted reader skims them to decide whether to read at all. That is their primary job, and it is a real job.

For search engines, headings help identify what each section covers. Google has stated that heading order is not a significant ranking factor — using them correctly will not move you up, and a messy outline will not by itself push you down.

The H1 question

Having more than one H1 is valid HTML5 and Google handles it without complaint. The argument for a single H1 is about clarity: a page with three H1s usually has three competing ideas about what it is about, and that ambiguity tends to show up in the snippet it earns.

The most common real problem is templating — a theme that renders the site name as an H1 on every page, pushing the actual page title down to H2. If your page titles are H2s site-wide, that is worth fixing.

Skipped levels

Going from H1 to H3 breaks the outline. For a screen reader, encountering a level 3 with no level 2 above it makes the hierarchy ambiguous. The fix is trivial: either promote the heading or introduce the missing level.

Never choose a heading level for its font size. Style headings with CSS and pick levels purely for structure. If your H3 looks better than your H2, restyle the H2.

Writing headings that work

Describe the section concretely. 'How the payout is calculated' beats 'Calculation'; 'What breaks on mobile' beats 'Mobile'. A heading should be understandable when read out of context, because that is exactly how most people encounter it.

Length matters less than specificity, but a heading over about 70 characters stops being scannable. If you need that many words, the section is probably two sections.

Separating structure from styling

The reason heading structure goes wrong so often is that HTML gives you six levels and design gives you three or four type sizes. When a designer needs a small bold line that is not a heading, the tempting move is to use an H5 and style it down. That works visually and breaks the outline.

Do it the other way around. Choose the level for meaning, then style each level in CSS to whatever the design needs. An H2 can be 15px if that is what the layout calls for — nothing in HTML says an H2 must be large. Once levels stop carrying visual meaning, you can use them purely for structure, which is the only thing they were ever for.

Checking a page in under a minute

Paste the page HTML into the analyzer and read the outline, not the issue count. If the H2 list reads like a table of contents, the structure is fine and the remaining warnings are cosmetic. If it does not, you have found the real problem — and it is usually that the page covers two topics and should be split, or that sections were never given headings at all.

Repeat for your five most important pages. Structure problems are almost always systemic: a template writes the same bad outline on every page, so fixing one usually means fixing hundreds.

A site adds an Organization block to the footer, an Article block to the article template, and a BreadcrumbList to the breadcrumb component. Three separate <script type="application/ld+json"> blocks, each describing one thing. It works — Google reads all of them — and it is where most sites stop.

The cost is not visible immediately. It shows up the first time you rename your company, change your logo URL, or move to a new domain. Now you have three places that each contain the same facts, and nothing enforces that they agree. One gets updated, the others do not, and the structured data on your site now contradicts itself in a way no error message will tell you about.

What @id actually does

Every node in JSON-LD can carry an @id, which is a stable identifier — a URL is conventional. Once a node has an @id, any other node can refer to it by that identifier instead of repeating its properties.

So instead of the Article block containing its own copy of the publisher's name and logo, it contains "publisher": { "@id": "https://example.com/#organization" }. The full description of that organization lives once, in a node that other nodes point at. Change the logo in that one place and every reference is correct.

The practical payoff is that your structured data becomes a description of relationships rather than a set of isolated assertions. This article was published by that organization, on this website, and sits at this position in this breadcrumb trail. All of it expressed explicitly rather than inferred.

The shape that works

A layout that has held up well across several sites: one @graph array in the page head containing, in order, the Organization, the WebSite, the WebPage for the current URL, and then whatever page-specific nodes apply — an Article, a FAQPage, a HowTo, a Product.

The Organization and WebSite nodes are identical on every page, which is the point: they are declared once per page but defined consistently, and every page-specific node references them by @id rather than restating them. The WebPage node carries datePublished and dateModified, and the page-specific nodes carry their own.

Breadcrumbs attach to the WebPage rather than floating free, because a breadcrumb trail describes a position within a site hierarchy, and the hierarchy belongs to the page.

Where this goes wrong

Referencing an @id that does not exist on the page. If the Article says its publisher is #organization but no node with that @id is present, the reference resolves to nothing. Google handles this by ignoring the property, so the symptom is not an error — it is silently missing data. Always include the node you reference.

Using the same @id for different things. Identifiers must be unique. Two nodes sharing an @id means you have declared two contradictory definitions of one entity, and the outcome depends on which one a consumer reads first.

Absolute versus relative @id values. Use absolute URLs. A relative reference like #organization is interpreted against the page URL, which means the same markup on two domains produces two different identifiers, and any relationship you were trying to express across pages breaks.

Dates deserve their own paragraph

datePublished should never change after the page goes live. dateModified should change when the content genuinely changes, and not otherwise.

Incrementing dateModified on every deploy is a common habit, usually adopted because someone believed freshness helps rankings. It does not, and the pattern is easy to detect: a modified date that advances daily while the words stay identical tells any consumer that the field is noise, which means it will be discounted on the pages where it was actually true.

If you use a build system, wire dateModified to a per-page content hash rather than to the build timestamp. That way the field moves only when the content does.

Checking your markup

Validate with Google's Rich Results Test for eligibility and the Schema Markup Validator for syntax. Neither will tell you that your @id references are dangling, because a dangling reference is not a syntax error.

The check that catches it is manual and takes a minute: extract the list of @id values defined in the page, then extract every value used in a reference, and confirm every reference appears in the defined list. On a page with six nodes this is faster to do by eye than to automate.

Every item here has a dedicated tool on this site, and you can run them in any order. The reason to work from a list is that the failure mode is not a broken page — it is a page that looks finished. A missing canonical, a duplicate H1, a description that gets truncated: none of these produce a visible symptom. The page renders, the content is good, and the problem is only discoverable weeks later in a report nobody reads closely.

The order below is deliberate. Structural checks first, because fixing them often changes the text, and re-running content checks after a rewrite wastes the first pass.

1. Does the page have exactly one H1?

Not zero, not two. Zero usually means the title was styled with a class rather than a heading element. Two usually means a template printed the site name as an H1 and the page title as another. Both are invisible in a browser and both make the page's main subject ambiguous.

Run the HTML through the heading analyzer and read the outline rather than the warnings. If the H2 list reads like a table of contents for the page, the structure is sound.

2. Do the heading levels descend without skipping?

An H2 followed by an H4 tells a reader that a level is missing. Sometimes a level genuinely is missing and the outline is still correct — but more often the H4 was chosen for its smaller font size. Choose levels for meaning and style them in CSS; nothing in HTML requires an H2 to be visually larger than an H3.

3. Is the title tag specific to this page?

Open ten tabs of your site and read the titles. If several are identical, those pages compete with each other for the same query and none of them wins clearly. A title should describe what this page specifically covers, not the category it belongs to.

4. Will the description survive truncation?

The widely quoted 155-character limit is an average, not a rule — the real constraint is rendered pixel width, and mobile is narrower than desktop. Put the sentence that must survive in the first 120 characters and treat the rest as elaboration. See the full explanation if you want the details.

Preview it rather than counting: the SERP preview tool measures in pixels and shows exactly where the cut lands.

5. Does the canonical point at itself?

A page's canonical should be its own URL, in the same form the page is served at. Trailing-slash mismatches are the common case: if /tools redirects to /tools/, the canonical must say /tools/, or you are telling Google that the real page is a URL that redirects.

Check this on index pages specifically. They are the ones most often generated with a canonical that omits the trailing slash.

6. Is the page in the sitemap, with the right URL form?

Same trailing-slash question. A sitemap entry that redirects is a wasted crawl. If your sitemap is generated, generate the canonical at the same time from the same value — two independent string constructions will eventually disagree.

7. Are the internal links real and useful?

Every new page should link to at least two existing pages, and at least one existing page should link to it. A page that nothing links to is a page that is hard to find, and internal links are the only navigation signal you fully control.

Link with descriptive anchor text. "Read the guide" tells a reader nothing about where it goes; the text should describe the destination.

8. Do images have dimensions and alt text?

Set explicit width and height attributes on every image. Without them the browser cannot reserve space, and the page shifts as images load — which is the single most common cause of a poor layout-shift score.

Alt text describes the image for someone who cannot see it. If the image is purely decorative, an empty alt="" is correct and better than a description nobody needs.

9. Does the structured data describe this page accurately?

If you mark up an Article, the headline should match the visible title and the dates should be real. If you mark up an FAQ, those questions must be visible on the page — markup describing content that is not there is a violation, not an optimisation.

See the @graph guide for how to keep the nodes consistent, or generate the markup with the schema generator.

What is deliberately not on this list

Keyword density. There is no target to hit, and writing to one produces worse text. Run the density checker only to see whether the page is actually about the topic you intended — if the top phrases surprise you, that is a content problem, not a density problem.

Word count. Length is a consequence of covering the subject, not a goal. A page that answers the question in 400 words is finished; padding it to 1200 makes it worse.

Meta keywords. They have been ignored for over a decade.

On 2026-09-23 we fetched https://<domain>/robots.txt for 78 high-traffic domains spanning news, ecommerce, SaaS, developer, social, finance, education and government categories. Of those, 71 returned a usable plain-text file. Two returned HTML instead of robots.txt, and five could not be read at all — four behind bot protection returning HTTP 403 or 418, and one returning 404 because no file exists.

Fetching used curl from a single machine with a two-tier transport: direct connection first, then a local proxy for domains the direct route could not reach. 46 of the 71 files came back over the direct connection and 25 over the proxy. That split is a property of our network rather than of the sites, and it is not distributed evenly across categories — which is the main caveat on everything below.

Parsing was done line by line, with user-agent groups respected. A Disallow: / that applies only to a scraper group is not treated as applying to Googlebot. The script and the domain list ship with this site, so every number here can be re-derived rather than taken on trust.

Finding 1: 24% declare no sitemap

54 of the 71 sites (76%) declare at least one sitemap, and 26 declare more than one. The other 17 declare none at all:

forbes.com, amazon.com, etsy.com, shopify.com, github.com, gitlab.com, reddit.com, linkedin.com, quora.com, npmjs.com, python.org, go.dev, mozilla.org, w3.org, ahrefs.com, screamingfrog.co.uk, mit.edu

Two things make that list worth reading. First, it contains sites with enormous page counts — Amazon, LinkedIn, Reddit — where a sitemap would seem most useful. Second, it contains two companies that sell SEO tools. That is not hypocrisy; it is evidence that the robots.txt sitemap line is genuinely optional in practice.

Be precise about what "no sitemap line" means. It does not mean the site has no sitemap. A sitemap can be submitted directly in Search Console and never mentioned in robots.txt, which is a valid setup and arguably the cleaner one — the file stays about access control, and discovery is handled where discovery is managed. What the omission does mean is that any crawler relying on robots.txt to find sitemaps will not find these ones.

If you are unsure whether your own file is read the way you think it is, paste it into the robots.txt tester and run a few real URLs through it.

Finding 2: Crawl-delay is still shipping, and Google ignores it

Five sites put Crawl-delay in the User-agent: * group: x.com, tumblr.com, vimeo.com, semrush.com and searchengineland.com.

Crawl-delay is not a Google directive. Googlebot has never supported it, and crawl rate is controlled in Search Console instead. So for the crawler it was most likely written for, the line does nothing.

It is not harmless, though. It is a signal that whoever maintains the file believes it controls crawl rate — and when that belief is wrong, the decisions made from it are wrong too. On a site genuinely being crawled too hard, the fix is the crawl rate setting, not a line in robots.txt.

One site in the sample uses Crawl-delay in a way worth copying rather than fixing. See the aside further down.

Finding 3: sitemaps that point somewhere else

Two sites declare a sitemap on a host other than the one being crawled.

notion.so declares eleven sitemaps, all on www.notion.com. That is a brand migration caught mid-flight — the .so domain being retired in favour of .com, with the old host's robots.txt pointing at the new one. It works, but the .so file can no longer be removed without breaking discovery for anyone still crawling it.

trello.com declares exactly one sitemap, on a594014.sitemaphosting7.com — a third-party sitemap host, not a Trello domain. Cross-host sitemap declarations are valid and Google accepts them, but they hand part of your discovery infrastructure to a domain you do not control. If that host changes its URL scheme or disappears, the declaration stops working silently.

Finding 4: http:// in a 2026 sitemap line

Two sites declare sitemap URLs over plain HTTP: theguardian.com and who.int.

The URL is followed with a redirect, so it usually still resolves. But it is a needless hop, and on sites that moved to HTTPS everywhere else it is the kind of leftover that suggests the file has not been reviewed in years. The check takes seconds: search your robots.txt for http:// and replace it with https://.

Finding 5: two sites serve HTML at /robots.txt

khanacademy.org and cdc.gov both return HTTP 200 with an HTML document at /robots.txt.

This is a soft 404: the request succeeds, so nothing alerts, but the content is not a robots.txt file. A crawler parsing it finds no directives and falls back to "everything allowed" — the same outcome as an empty file. The failure is invisible in a browser and invisible to a status-code monitor. It is exactly the class of problem a plain-text check catches and a dashboard does not.

What we did not find: nobody blocks their own sitemap

Before running this, we expected a handful of sites to declare a sitemap and then block it with their own Disallow rule — a classic own-goal that appears in most lists of robots.txt mistakes, including our own.

Zero out of 71 did.

That is worth stating plainly. The mistake is real and worth checking for, but across a sample this size it did not occur once. Advice can be technically correct and still miscalibrated about how often the problem actually happens — and the way to find out is to look, not to repeat the list.

An aside worth stealing: github rate-limits AI crawlers

github.com's robots.txt contains 13 user-agent groups, and one of them is a block listing GPTBot, OAI-SearchBot, ClaudeBot, anthropic-ai and PerplexityBot, carrying Crawl-delay: 1.

So that Crawl-delay is not a mistake. It is aimed at AI crawlers rather than Googlebot, and it is a deliberate attempt to slow bulk training and answer-engine fetching without touching search crawling. Whether the receiving crawlers honour it is a separate question — most have not committed to it — but the structure is a reasonable pattern: one group for search, another for AI, different policies in each.

If you are trying to control AI crawlers, that separation is the part worth copying. The llms.txt generator covers the other half of the same problem.

What to check on your own site

Does /robots.txt return plain text? Curl it and read the first line. If you see <!DOCTYPE, you have a soft 404 and none of your directives are being applied at all.

Is every declared sitemap on your own host? Cross-host declarations work until they don't.

Is there an http:// anywhere in it? Replace it with https://.

Is Crawl-delay in there? If it targets Googlebot, delete it and use the crawl rate setting. If it targets AI crawlers, keep it but give it its own user-agent group.

Does your sitemap URL form match your canonical URL form? An entry that redirects is a wasted crawl. This is the same trailing-slash question covered in the pre-publish checklist.

Limitations

Seventy-one sites is a sample, not a census, and it is not random. The domains were chosen by hand to span categories, which makes them representative of "well-known sites" rather than of "the web". Sites behind bot protection are systematically missing, and those are disproportionately large and heavily defended — so the true rate of unreadable robots.txt files is likely higher than the 5 in 78 measured here.

robots.txt is also a moving target. Files change without notice and this is a single-day snapshot, so the counts are a point-in-time measurement rather than a standing fact. Where a specific site is named, the raw body we retrieved is the arbiter.

Reproduce it

The survey script and the domain list are part of this site's source. It runs in about a minute and writes a per-domain table plus the raw files, so any claim on this page can be checked against the source text instead of taken on our word.

If you spot an error in a specific row, the raw body settles it — and corrections are welcome via the contact page.

On 2026-09-23 we fetched the homepage of 78 well-known domains and extracted every <script type="application/ld+json"> block from the response. 61 returned a usable page — 42 over a direct connection and 19 over a local proxy. Of those 61, 32 contained at least one JSON-LD block.

One caveat governs everything below, so it belongs at the top rather than the bottom: this measures what is present in the server-rendered HTML. A page that injects its structured data with JavaScript will look empty here even though a browser — and Google, which renders — would see it. Single-page applications are the obvious case. So when this article says a site "ships none", read it as "none in the initial HTML response", which is a different and weaker claim.

For the sites where we did find markup, that caveat disappears: everything about blocks, @graph, @id and node types is measured on markup that was actually present.

Finding 1: about half ship nothing in the HTML

29 of the 61 homepages contained no JSON-LD block at all. The list includes github.com, youtube.com, wikipedia.org, w3.org, mozilla.org, linkedin.com, x.com, spotify.com, npmjs.com, nodejs.org, kubernetes.io, mit.edu, stanford.edu, khanacademy.org, theguardian.com, slack.com, notion.so, trello.com, tumblr.com, vimeo.com, archive.org, wikimedia.org, digitalocean.com, squareup.com, uber.com, cdc.gov, go.dev, rust-lang.org and developer.mozilla.org.

Some of those are certainly JavaScript-rendered and will have markup in a browser. But wikipedia.org is not a JavaScript application, and neither is w3.org or github.com — those responses were 119KB, 51KB and 576KB of ordinary server-rendered HTML with no structured data anywhere in them.

The honest conclusion is narrower than "half the web has no structured data" and more useful than nothing: shipping JSON-LD is a choice that a large share of serious sites have not made, and it is not a precondition for ranking.

Finding 2: 14 sites still ship markup for a retired feature

This was the most surprising result. Google retired the sitelinks search box on 21 November 2024 — the search field that used to appear under a brand's result. The markup that powered it, a SearchAction on the WebSite node, now produces nothing.

Fourteen of the 32 sites with JSON-LD still carry it: cnn.com, forbes.com, walmart.com, atlassian.com, zoom.us, pinterest.com, docker.com, python.org, screamingfrog.co.uk, yoast.com, cloudflare.com, heroku.com, airbnb.com and who.int.

Two of those are SEO tool vendors. That is the interesting part: this is not a case of amateurs leaving stale markup around. It is a case of markup that was correct when it was written, that nothing broke when it stopped mattering, and that no tool flags because it is still valid schema.org. There is no error, no warning, and no rich result — just a few lines of JSON that no longer do anything.

It is worth being fair about this: leaving it in place costs nothing measurable. We are not suggesting the markup is harmful. The point is that it is invisible dead weight, and the only way to notice is to know the feature was retired — which is exactly the kind of thing that a site audit will never tell you.

If you are auditing your own markup, this is the check that pays: is any of it aimed at a feature that no longer exists? The schema generator on this site does not emit SearchAction for that reason.

Finding 3: a single block is the norm, and @graph is the minority

Of the 32 sites with markup, 24 used exactly one block, four used two, three used three, and one used four. So the "many small blocks" pattern that our @graph guide warns about is not actually the common shape — one block is.

Within that single block, however, the split matters. Only 13 of the 32 (41%) use a @graph array. The rest put a single node at the top level.

The 13: gitlab.com, atlassian.com, zoom.us, asana.com, docker.com, twitch.tv, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, stripe.com, netlify.com and heroku.com.

Look at that list again. Four of the thirteen are SEO tool vendors or SEO publications — Moz, Screaming Frog, Yoast and Search Engine Journal. When the people who build the tooling converge on a pattern, that is usually worth more than a spec reading, and it is consistent with the argument in the @graph guide: one connected graph beats several disconnected blocks.

Finding 4: most markup is boilerplate

Twenty of the 32 sites ship only generic node types — Organization, WebSite, WebPage, ContactPoint, PostalAddress — with nothing specific to the page being viewed.

The type frequency across all 32 tells the same story. The most common types were PostalAddress (33 occurrences), Organization (25), Place (24), WebSite (20) and ImageObject (20). BreadcrumbList appeared 6 times. SoftwareApplication 6 times. VideoObject 6 times.

More addresses than web pages. For a homepage that is defensible — the homepage is where the organization describes itself. But it means that on most of these sites, the structured data says "here is a company" and never says "here is what this particular page is about".

Finding 5: the pattern at full size

stripe.com packs 54 nodes into a single @graph — by a wide margin the largest we found, and more than the next three sites combined.

That is the @graph pattern doing what it is for. Fifty-four connected nodes with @id references resolve to one coherent description of the site rather than fifty-four independent assertions that must agree with each other by hand.

What we did not find: almost no dangling references

Our @graph guide warns that referencing an @id which is never defined causes the property to be silently ignored. We expected to find this in the wild.

One site out of 32 — paypal.com, with a single reference to https://www.paypal.com/c2/home#website that no node defines.

Two other things we expected and did not find: zero JSON parse failures across every block we extracted, and no site shipping markup in more than four blocks. Invalid JSON-LD and block sprawl both turn out to be much rarer than the advice would suggest.

This is the second time in two surveys that a widely repeated warning did not appear at all in a sample of this size. That is not an argument for ignoring the warnings — a dangling reference is still a bug — but it is an argument for checking how often the thing you are worried about actually happens before you spend a week refactoring.

What to check on your own markup

Is any of it aimed at a retired feature? SearchAction is the one to search for today. Check the markup against the current list of supported rich results rather than against a tutorial you followed in 2023.

Does it say anything about this page? If every page on your site emits the same Organization and WebSite nodes and nothing else, the markup is describing your company and not your content.

Is it one connected graph or several disconnected blocks? Neither is an error. One is easier to keep consistent.

Does every @id you reference exist on the page? Extract the defined @id values and the referenced ones and compare the lists. It takes a minute by eye on a page with under ten nodes.

Limitations

The sample is 61 reachable homepages chosen by hand to span categories — representative of well-known sites, not of the web. Homepages only: article, product and FAQ markup lives on inner pages and is not measured here.

The server-rendered caveat is the big one. Any JavaScript-injected markup is invisible to this method, so the true rate of sites using structured data is certainly higher than 52%. The findings about @graph, node types and SearchAction are drawn only from markup we actually retrieved, so they are unaffected — but the headline number is a floor, not a rate.

Finally, this is a single-day snapshot of pages that change constantly.

Reproduce it

The extraction script and the domain list ship with this site and run in about two minutes. It writes the extracted JSON-LD for every domain, so each claim above can be checked against the markup itself rather than our summary of it.

If a row is wrong, the markup settles it. Corrections via the contact page — and if you know why the sitelinks search box markup is still so widespread two years after retirement, we would like to hear that too.

On 2026-09-23 we fetched the homepage of 78 well-known domains and parsed every <meta> tag whose property or name began with og: or twitter:. 62 returned a usable page — 41 over a direct connection and 21 over a local proxy.

Two counting rules governed everything below, and both changed the numbers. First, a tag whose content attribute is empty or missing counts as absent: og:title="" is a tag that exists and says nothing. Second, nothing was rendered — this is what the server returned, so any tag injected by JavaScript is invisible here. That caveat bites less for social tags than it did for our JSON-LD survey, because social metadata is usually server-rendered precisely because crawlers do not run JavaScript, but it still makes these figures a floor rather than a rate.

Finding 1: Open Graph is near-universal; Twitter cards are not

56 of the 62 homepages (90%) carried at least one Open Graph tag. But "90% have Open Graph" hides how patchy the individual fields are:

og:title 54/62 (87%) · og:description 53/62 (85%) · og:url 49/62 (79%) · og:image 48/62 (77%) · og:type 48/62 (77%) · og:site_name 40/62 (65%) · og:locale 22/62 (35%).

So roughly one homepage in four has no shareable image at all. That is not a ranking problem — Open Graph has no effect on search — but it is a click problem, and it is invisible from inside the site because everything looks fine.

The Twitter side is where the real gap opens. 34 sites (55%) declared twitter:card as summary_large_image, 14 as summary, 2 as app, and 12 declared no twitter:card at all — about one in five. X falls back to Open Graph for title, description and image, but it still needs twitter:card to know which layout to build. Without it you get a plain link, no matter how good the Open Graph tags are.

Finding 2: two sites ship an og:image tag with nothing in it

We expected this to be common, because it is the mistake that produces a grey box: a site declares a large-image card and supplies no image. It turned out to be rare — 2 of the 34 sites declaring summary_large_image had no usable og:image.

Both are worth looking at, because they fail in different ways.

netflix.com declares twitter:card = summary_large_image and twitter:site, and nothing else — no og:image, no og:title, no og:url. The card type promises a large image that was never supplied.

forbes.com is the more instructive one, because it does emit the tag:

<meta property="og:image" name="image" data-next-head=""/>

There is no content attribute at all. The tag is present, a checker that asks "does og:image exist?" answers yes, and there is no image. Its twitter:image has the same shape, and its og:image:type is image/jpeg,image/gif,image/png — a comma-separated list, which is not a single MIME type and is not a valid value for that field.

This is the failure mode worth remembering, because it is the one automated checks miss. A missing tag fails loudly. A present-but-empty tag passes every "is it there" check and renders nothing.

We should be candid that we had this backwards. Until the day this data was collected, every one of the 25 pages on this site declared twitter:card = summary_large_image with no og:image — the pattern that turns out to be rare in the wild. It is fixed now, and that fix is what led to the next finding.

Finding 3: only 23% declare image dimensions

Of the 48 homepages with a usable og:image, just 11 (23%) also declared og:image:width and og:image:height. The rest leave the scraper to download the image and work out the layout for itself.

That sounds harmless until you think about what happens on the first share. The platform has to fetch the image before it can build the card. If that fetch is slow, rate-limited or blocked — a CDN that dislikes the crawler's user agent, a region where the image host is slow — the first share goes out with no image and the second one works. An intermittent bug like that is far harder to diagnose than a missing tag.

The 11 that declare dimensions: figma.com, x.com, docker.com, developer.mozilla.org, w3.org, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, harvard.edu and heroku.com.

Four of those — Moz, Screaming Frog, Yoast and Search Engine Journal — are SEO vendors or SEO publications. All four SEO sites in the sample declare dimensions, against 23% overall. They are the same four that showed up as @graph users in our JSON-LD survey, which is a consistent signal: the sites whose business is this metadata treat it more carefully than average by a wide margin.

Only 5 of the 48 (10%) declared og:image:alt. Alternative text on a social card is not decorative — it is what a screen reader announces.

Finding 4: one in four og:title disagrees with the title

14 of the 54 homepages with both a <title> and an og:title showed different text in each — 26%.

Most are trivial: github.com drops a trailing "· GitHub" from the Open Graph version. Some are not. kubernetes.io has <title>Kubernetes</title> alongside og:title = Production-Grade Container Orchestration, so the search result says one thing and the shared link says another. asana.com ships "Work & Project Management for Human-Agent Teams • Asana" as its title and "Asana: The OS for human-agent teams" in the card.

Neither is wrong. But it means the title you optimise for search is not the title people see when the page is shared, and those are usually written for different purposes. If you only ever check one, check the one that appears in search.

Finding 5: what we expected and did not find

Across the 48 usable images: one relative path — kubernetes.io, at /images/kubernetes-open-graph.png — zero http:// images, and zero sites declaring more than one og:image.

Relative og:image URLs are the classic warning: scrapers have no base URL to resolve against, so the tag gets dropped. It happens once in 48. Insecure images, not at all. This is the third survey in a row where a widely repeated warning turned out to be rare at this sample size — which is not an argument for ignoring the warnings, but is an argument for checking the base rate before spending a day on the thing you are worried about.

What to check on your own tags

Is the image tag carrying anything? View source and look for content=. A tag with no content attribute is the one check a validator will not do for you.

Do you declare width and height? Two lines, and it removes the "first share has no image" failure mode entirely.

Do you declare twitter:card? One in five sites we checked skip it, and it is the difference between a card and a bare link.

Does og:title match your title? If not, decide which one you meant and make them agree — or accept that you have written two titles and maintain both.

The Open Graph Preview renders what your tags will actually produce, and the meta tag generator emits the full set including dimensions and alt text.

Limitations

62 homepages chosen by hand to span categories — representative of well-known sites, not of the web. Homepages only; article and product pages carry different tags and are not measured here.

Server-rendered HTML only, so JavaScript-injected tags are invisible and the 90% figure is a floor. Empty and missing content attributes count as absent, which is the stricter reading — the 77% with a usable og:image would be slightly higher if a present-but-empty tag counted.

A single-day snapshot of pages that change constantly.

Reproduce it

The extraction script and the domain list ship with this site and run in about two minutes. It stores the raw HTML for every domain, so each claim above can be checked against the markup itself rather than our summary of it.

If a row is wrong, the markup settles it. Corrections via the contact page.