# 85 meta elements in five page heads, and two addressed a crawler > Counted with an HTML parser on 24 August 2026 over five real pages this scanner captured and stored on 15 July 2026, the head of those documents holds 85 meta elements. Two are a robots meta tag, and both of those carry nothing but an image preview size. Five of the five tell a social network how to draw a card. - Canonical page: https://lantad.co/blog/eighty-five-meta-elements-two-addressed-a-crawler - This file: https://lantad.co/blog/eighty-five-meta-elements-two-addressed-a-crawler.md - Last substantive update: 2026-08-24 ## Key facts - **Published:** 2026-08-24 - **Category:** Findings - **Author:** Lantad - **Length:** 3707 words - **Takeaway 1:** Counted with an HTML parser on 24 August 2026 over five real pages this scanner captured and stored on 15 July 2026, the raw HTML holds 85 meta elements: 51 carrying a name attribute, 28 carrying property, five carrying charset and one carrying http-equiv. - **Takeaway 2:** Two of the 85 are a robots meta tag, on astro.build and on Wikipedia, and both carry only an image preview size. Zero of the 85 carry a name of googlebot or of any AI crawler vendor, while all five pages carry a twitter:card declaration. - **Takeaway 3:** Google's robots meta tag documentation, carrying Last updated 2026-03-24 UTC, defines max-image-preview as the maximum size of an image preview in search results, and states that a page with no robots meta tag may be indexed and shown with Google choosing the presentation. - **Takeaway 4:** The 85 meta elements are identical in the rendered DOM and in the raw HTTP response on all five pages. The link elements in the same heads are not: they go from 217 to 225 once JavaScript has run. - **Takeaway 5:** Lantad's extractor reads six of the 85, the four meta descriptions and the two robots tags, and the three head signals in its structure sub-score are presence checks worth 6.9 points of the composite 100 between them. ## Summary The head of an HTML document is where a page is supposed to say what it is and who may do what with it. Every meta tag that governs an AI crawler's use of a page lives there, or in the response header that mirrors it, so it is worth asking what real page heads actually contain rather than what the advice says they should. This post counts that on the only pages this site is entitled to count: the five real captures already frozen in its own fixtures. The measurement is narrow and the limits are set out at the end. Five pages is not a sample of the web, all five were captured on one day, and nothing here observes what any [AI crawler](https://lantad.co/glossary/ai-crawler) does with what it finds, because a stored page cannot show that. What the count does settle is which declarations are present, which specification permits each of them, and how few of them our own scanner reads. The same five fixtures produced earlier counts of [alt text on 466 images](https://lantad.co/blog/alt-text-on-466-captured-images) and of [85 links with no anchor text](https://lantad.co/blog/textless-links-named-only-by-aria-label). This is the same exercise moved from the body to the head. ## What a meta tag can say to an AI crawler, and what these five said Eighty five meta elements sit in the raw HTML of the five pages. Sorted by how many of the five documents carry them at least once, the most common declarations are viewport and twitter:card, each on all five, then description on four, then generator and theme-color on three each. The robots meta tag is on two. Nothing else in the set is on more than two pages. That ordering is the finding, and it is worth stating without commentary about intent. Every one of these five pages carries an instruction about how a social network should draw a preview card. Two of them carry any instruction at all directed at the software that fetches pages for search or for an answer engine. Whatever the reason, the head as published is far better provisioned for the card than for the crawler. The absences are as specific as the presences. Not one of the 85 carries a name of googlebot, which is the value Google documents for addressing its text search crawler on its own rather than through the shared robots name. Not one carries a name belonging to any AI vendor. That last absence is unremarkable once you know the field: OpenAI, Anthropic and Perplexity all publish crawler documentation that gives site owners a robots.txt token rather than a meta name, which is why [our crawler registry holds fifteen tokens](https://lantad.co/bot) and no meta directives from those three. Microsoft is the exception that proves the shape of it, because [Microsoft's AI opt out is a meta tag rather than a robots.txt token](https://lantad.co/blog/microsoft-ai-opt-out-is-a-meta-tag), and no page in this set carries that either. One more count belongs here because it is the one nobody expects. All 85 meta elements are present, unchanged and identical in the rendered DOM. Not one of the five pages adds, removes or edits a meta element when JavaScript runs. The link elements in the same heads do move, from 217 in the raw response to 225 after rendering, all eight of the additions on two pages. So the part of the head that carries directives is static on every page here, while the part that carries relationships is not, which is a distinction worth knowing if you have ever been told to check a page twice. We have measured the same split in the body, where [JavaScript added no new crawl paths](https://lantad.co/blog/javascript-added-no-new-crawl-paths) across these same captures. ## Two robots meta tags, and both of them are about images The two robots tags say max-image-preview:large on astro.build and max-image-preview:standard on Wikipedia. Neither says anything else. [Google's robots meta tag documentation](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag), carrying Last updated 2026-03-24 UTC, defines the rule as setting the maximum size of an image preview for the page in search results, and defines the two values these pages use: standard means a default image preview may be shown, and large means a larger image preview, up to the width of the viewport, may be shown. Read that against what the same page says a robots meta tag can do. It documents noindex, which keeps a page out of results entirely. It documents nosnippet, which suppresses the text snippet. It documents max-snippet, which caps the snippet at a stated number of characters. All three concern text, all three are the rules that actually bear on whether a passage of your page can be quoted, and none of the five pages here uses any of them. The documentation is also explicit about the default, and the default is the point. It states that without a robots meta tag the page, media or resource may be indexed and shown in search results, with Google determining the presentation parameters. So the three pages with no robots tag have not declined to answer. They have accepted the vendor's defaults, which is a decision even when nobody made it deliberately. The gap between that and an AI answer is the part this post cannot close, and it is the reason we published [an audit of the one Google crawler our scanner does not model](https://lantad.co/blog/ai-overviews-and-the-crawler-we-do-not-model). Google's directives are documented against Google Search surfaces. Whether an image preview size influences what an answer engine quotes is not something the documentation claims, not something we have measured, and not something a stored HTML file could show. What can be said from the file is narrow and true: on five real pages, the only crawler-directed declarations present were about pictures. ## Twenty eight meta elements carry an attribute the HTML specification does not list Split the 85 by which attribute identifies them and the arithmetic is exact: 51 carry name, 28 carry property, five carry charset, one carries http-equiv, none carries itemprop, and no element carries two of them. The WHATWG HTML Living Standard, read at https://html.spec.whatwg.org/multipage/semantics.html on 24 August 2026, states that exactly one of the name, http-equiv, charset and itemprop attributes must be specified on a meta element. Property is not among the four. Twenty eight of 85, a third of every meta element in this set, is therefore not conforming to the HTML specification on its own terms. Nothing is broken and nobody should change anything, because a second specification permits it. [HTML+RDFa 1.1 Second Edition](https://www.w3.org/TR/html-rdfa/), a W3C Recommendation dated 17 March 2015, states that if the RDFa property attribute is present on the meta element then neither name, http-equiv nor charset is required, and the content attribute must be specified. Open Graph is built on RDFa, which is how the most widely deployed metadata format on the web came to sit outside the content model of the document format that carries it. RDFa and JSON-LD are two ways of doing the same job, and the one our schema check actually reads is the other one, described in our note on [structured data](https://lantad.co/glossary/structured-data). Twenty four of the 28 carry an og value. The remaining four are a fb:pages on webflow.com, a Wikipedia property named mw:pageprop/toc, and two position properties on the MDN page, which are RDFa breadcrumb positions rather than social markup. The interesting page is MDN, and it is interesting because it does the same job the other way round. Its head carries ten og values written as name rather than as property: og:url, og:title, og:locale, og:description, og:site_name and five og:image variants. That spelling is conforming HTML and it is not what the Open Graph documentation shows. So a parser written strictly to the HTML specification reads MDN's Open Graph and misses everyone else's, and a parser written to Open Graph convention reads everyone else's and misses MDN's. Neither page is wrong. A consumer that reads only one attribute is. This is the same class of problem as the one behind [reading a page's structured data twice and getting a different answer](https://lantad.co/blog/structured-data-measured-twice). The markup is a claim, the reader is a program, and the disagreement lives in which specification the program was written against rather than in the page. ## Thirty title elements on five pages, and twenty five were inside an SVG The five documents contain 30 title elements. Five of them are the document title. The other 25 are inside an inline SVG, 22 on webflow.com and three on the MDN page. The SVG titles read Play, Pause, Webflow, Made in Webflow, YouTube, X, Facebook, Linkedin, MDN and Mozilla, which is to say they are icon labels. Two specifications are in play and they do not conflict. The WHATWG HTML Living Standard states that there must be no more than one title element per document, and that the title element represents the document's title or name. [The SVG title element](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/title) is a different element in a different namespace: MDN describes it as providing an accessible, short-text description of any SVG container or graphics element, and notes that its text is not rendered as part of the graphic but that browsers usually show it as a tooltip. Every page here is conforming. Webflow has one document title and 22 accessible names for icons. The trap is on the reading side, and it is worth naming because it is easy to fall into and impossible to see afterwards. Ask a parser for title elements and you get 30. Ask it for the document title and you get five. A tool that took the first answer would report that webflow.com declares 23 titles, which is both false and the sort of false that survives review, because 23 is a real count of a real thing. Our own extractor does not fall into it, and the reason is a rule written for something else entirely. It drops the subtree of every script, style, noscript, template, svg and iframe element before any other handler runs, so a title inside an SVG is never offered to the title handler at all. That rule exists to keep icon labels and script bodies out of the corpus we compare when measuring [prose parity](https://lantad.co/glossary/prose-parity), and correct title extraction is a side effect of it rather than a case anyone designed for. We have published the opposite outcome from the same family of rules, where [an h1 inside a header element counted as no h1 at all](https://lantad.co/blog/an-h1-inside-a-header-counted-as-none), so it is only fair to record the case where the boundary rule lands the right way round. ## Which six of the 85 our scanner reads, and what it does with them Our extractor reads two meta names and no others. It reads name equals description, taking the first occurrence only, and it reads name equals robots, splitting the content on commas and keeping every token. On these five pages that is four descriptions and two robots tags: six meta elements out of 85. The remaining 79 are parsed as markup and then discarded, including every og value, every twitter value, the viewport, the generator, the theme colour and all 27 hreflang alternates. The string hreflang does not appear anywhere in the scanning library. What happens to the six is more limited still. The two robots tags are merged with any X-Robots-Tag header into one set of tokens, and that set is tested for exact membership of two strings, noai and nosnippet. An image preview directive matches neither, so on these five pages the directive test never fired. The four descriptions are tested for presence and non-emptiness and nothing else: the scanner does not ask whether a description describes the page, and the four here run from 107 to 276 characters without any of that mattering to the score. The canonical link is the case where presence-only checking costs the most, and it is worth being blunt about it. All five pages carry exactly one canonical and all five pass. Three of the five point at precisely the URL that was fetched. Two do not: gymshark.com and webflow.com both give a canonical with no trailing slash for a URL that was fetched with one. That particular difference is harmless, because an empty path and a single slash are equivalent for an HTTP URL, and it is the kind of thing a normaliser resolves without anyone noticing. The point is that our check would also have passed a canonical pointing at an unrelated page on another domain, because it only asks whether the href is there and non-empty. That is the honest description of the head as a scoring surface here, and it is the same discipline as [withholding a grade rather than printing a confident wrong one](https://lantad.co/blog/why-we-withhold-a-grade). A presence check is cheap, it is stable, and it is a genuinely useful floor. It is not a correctness check and we should not let a passing row read like one. We published the same gap in the markup layer, where [three captured pages scored full marks for schema and only one carried a date](https://lantad.co/blog/full-schema-marks-and-one-page-carried-a-date). The full deduction table sits on [the methodology page](https://lantad.co/methodology). ## What the head is worth in the score, and what this count cannot tell you Three of the seven checks in our structure sub-score read the head: a title is present, a meta description is present, a canonical is present. Each carries a weight of 1 in a set whose weights total 6.5, and the structure sub-score is 15 percent of the composite. So the entire head, as this scanner scores it, is worth 6.9 points out of 100, and every one of those points is a presence check. That is a setting somebody chose rather than a finding anybody measured, and the distinction matters enough that we keep repeating it: a weight in a config file and a number out of a scan look the same on a slide and only one of them survives being asked where it came from. The stored goldens agree with this post's independent parse, which is the only cross-check available here and worth stating as such. All five record titlePresent and canonicalPresent as true. Four record metaDescriptionPresent as true, and Wikipedia records it as false, which is the same four out of five the parser found. Two files, two readers, one answer. Now the limits, and they are wide. Five pages is not a sample of anything, and two of the five are marketing homepages, which are the most metadata-dense documents on the web and are not representative even of the sites they belong to. The captures are from a single day, 15 July 2026, and a head can change between deploys. This post reports what is in five stored files and what two specifications and one vendor's documentation say about the elements in them. It contains no evidence about crawler behaviour: nothing here shows that any AI crawler reads a robots meta tag, honours an image preview directive, or has ever looked at an og value. That would need a different measurement, of the kind our [crawlability research](https://lantad.co/research) exists to hold, and we have not run it for the head. If you want to check your own pages rather than read about ours, the useful order is short. Fetch a page the way a crawler would, without JavaScript, and read the head you actually get: [what GPTBot sees](https://lantad.co/tools/what-gptbot-sees) does that for one URL. Search the result for a robots meta tag and decide whether the defaults it is accepting are the ones you want. Confirm the canonical is the URL you meant, since nothing in our score will tell you if it is not. Then check that the description and the title describe the page, which is the part no presence check reaches and the part that ends up quoted, and while you are in the markup, check that your headings carry an id, because [55 of 245 headings on these same five pages did](https://lantad.co/blog/read-more-deep-links-and-heading-ids). That last one matters more for [generative engine optimisation](https://lantad.co/glossary/geo) than any directive in this post, because the directive governs permission and the text governs what there is to quote. The same logic runs through what we found about [three of five pages carrying JSON-LD](https://lantad.co/blog/three-of-five-pages-carried-json-ld) and about the [three table elements on those five pages that were all navigation](https://lantad.co/blog/three-tables-on-five-pages-all-navigation): the markup being present is the easy half. ## Questions and answers **Do AI crawlers read meta tags?** Google documents a robots meta tag and per-crawler names such as googlebot, and Microsoft documents NOCACHE and NOARCHIVE in a meta robots tag as its AI opt out. OpenAI, Anthropic and Perplexity publish crawler documentation that gives site owners a robots.txt token rather than a meta name. That is a statement about what is published, not evidence about behaviour: this post counted meta elements in five stored HTML files and observed no crawler at all. **How many meta tags does a real page have?** On the five pages Lantad captured on 15 July 2026 and counted on 24 August 2026, the heads hold 85 meta elements between them, from 14 on the Wikipedia article to 20 on astro.build. Four of the five carry a meta description and two carry a robots meta tag. Five pages is not a sample of the web, and two of the five are marketing homepages, which carry more metadata than most documents. **Why do Open Graph tags use property instead of name?** Because Open Graph is built on RDFa. The WHATWG HTML Living Standard states that exactly one of name, http-equiv, charset and itemprop must be specified on a meta element, and property is not among them. HTML+RDFa 1.1 Second Edition, a W3C Recommendation dated 17 March 2015, relaxes that: with the RDFa property attribute present, none of name, http-equiv or charset is required. Both spellings occur in the wild, and the MDN page in this set writes ten og values with name. **Does Lantad's AI visibility score check whether a canonical URL is correct?** No. It checks that a canonical link exists with a non-empty href, and that is the whole check. Two of the five captured pages give a canonical that differs from the fetched URL by a trailing slash, which is harmless, and both pass. A canonical pointing at an unrelated page would also pass. The three head checks in the structure sub-score are presence checks worth 6.9 points of the composite 100 between them. --- Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup. Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot