Meta tags for AI search: 38 of 1,083 home pages sent a crawler no name at all

Which meta tags for AI search does an answer engine actually read?

Only one publisher in this field documents the answer in enough detail to test, and it is Google. Google's documentation on influencing your title links, carrying Last updated 2025-12-10 UTC, lists the sources it uses to choose the title link for a result. There are nine of them: content in title elements, the main visual title shown on the page, heading elements such as h1 elements, content in og:title meta tags, other content that is large and prominent through the use of style treatments, other text contained in the page, anchor text on the page, text within links that point to the page, and WebSite structured data. The same page states that the process is "completely automated and takes into account both the content of a page and references to it that appear on the web", and that "if we've detected an issue on the page, we may try to generate an improved title link from anchors, on-page text, or other sources".

Two things follow from that list and both are worth holding onto. The first is that og:title is not decoration. It sits in the same enumerated list as the title element, which means a page that publishes two different names for itself is handing a title selector two candidates rather than one. The second is that the title element is not the only path in, so a page with no title is not automatically nameless: headings, prominent text and anchor text are all listed. That matters for the finding below, because it sets the bar for what "no name" honestly means. It means nothing in the head, not nothing anywhere.

The description half is documented more narrowly. Google's snippet documentation, carrying Last updated 2026-04-20 UTC, states that "Snippets are primarily created from the page content itself" and that "Google sometimes uses the meta description HTML element if it might give users a more accurate description of the page than content taken directly from the page". So the meta description is a candidate, not a guarantee, and it has been that way for years.

Worth noting that the ninth source on Google's list, WebSite structured data, is the only machine-readable one, and it is the least present of the lot: an earlier run of this corpus found 141 of 382 home pages carried no structured data at all in the raw HTML. The head is where the cheap signals live, which is why a five page precursor to this run counted 85 meta elements across five page heads and found two that addressed a crawler. This run is the same question asked of a thousand sites instead of five.

Nobody else publishes anything comparable. That is the honest limit on this whole subject, and this blog has measured its shape before: of the nine vendors behind the crawler tokens this scanner evaluates, only two state whether their crawler executes JavaScript at all. None of them documents what it does with a title element. The only thing either of Google's pages proves is that at least one large answer surface reads these tags and says which ones. For every other engine the honest position is that the tags are the cheapest thing on the page to get right and there is no published evidence about how each one weights them.

38 home pages gave a crawler no name at all

33 of the 1,083 pages carried no title element anywhere in the head. Five more carried a title element that was empty once whitespace was collapsed. None of those 38 carried a usable og:title either: one served an og:title element whose content was an empty string and the other 37 served no og:title at all. So as far as the delivered bytes were concerned, the page had no name. Because that is a surprising claim to make about hosts of this size, every one of the 38 was requested again later the same day in a single independent fetch, with the title, the og:title and the body word count all read from that one response. All 38 came back the same way. Not one recovered a name.

29 of the 38 carried fewer than 50 words of readable body text, which is the signature of a client rendered shell: the document is a mount point and the title is set by script after the bundle runs. That is the expected case and it is well covered here already, most directly in the finding that JavaScript supplied 7.6 percent of the prose across 271 pages and all of it on 11 of them, and in the older observation that text in hydration JSON scored the same as no text at all. Three of the 38 did not even manage a shell. ocado.com, klarna.com and sf.gov each answered HTTP 200 with a content type of text/html and a body of zero bytes, on both requests.

The nine that matter are the other kind. These pages sent a crawler real prose, hundreds or thousands of words of it, and still no name in the head. dr.dk delivered 4,102 words of body text and userloop.io delivered 4,079. nubank.com.br delivered 723, aboutyou.de 647, hoshinoresorts.com 278, calltree.ai 268, jonhanlan.me 231, visa.com 190 and patagonia.com 155. On those pages the content arrived and the label did not, which is the specific failure that no amount of rendering capability fixes for a crawler that reads bytes. It is also the failure that is easiest to miss from a desk, because whatever a browser puts in the tab after running the page's script is not what this measurement looked at, and a tab with a title in it is the check most people would make.

One more page deserves naming for a different reason. acog.org, the American College of Obstetricians and Gynecologists, serves a title element reading "value is what Coveo indexes and uses as the title in Search Results.--> Home | ACOG". The string carries a comment closing marker in the middle of it, so what reaches every surface that quotes the title is a fragment of the template's own instructions followed by the real name. That page has a name. It is just not only the name anybody chose.

On 214 pages the title element and the og:title did not match

883 of the 1,083 pages carried both a title element and an og:title. On 669 of them, 75.8 percent, the two strings were byte for byte identical after whitespace was collapsed. On 214 they were not. One of the 214 carried an og:title that was empty, leaving 213 real disagreements, and they can usefully be cut two ways.

122 of the 213 are the benign kind, where one string contains the other. Usually the title element carries the brand and the og:title drops it: blindpay.com sends a title of "BlindPay | Stablecoin API for global payments" and an og:title of "Stablecoin API for global payments", and promptless.ai sends "Continuously improve your AI workforce and docs | Promptless Documentation" against "Continuously improve your AI workforce and docs". A card on a social network sits next to the site's name already, so dropping the brand there is a reasonable design choice. It is worth knowing that the same string is a title link candidate, where the brand is the part that does the work.

The other 91 are pages where neither string contains the other. Cutting the 213 a second way finds the sharpest group in the set, and it does not sit neatly inside either bucket: on 29 pages the og:title is nothing but the word "Home", "Homepage", "Welcome" or "Start". 17 of those 29 fall in the 91, where the title element names the organisation and the og:title does not. imperial.ac.uk sends a title of "Imperial College London" and an og:title of "Home". gatech.edu sends "Georgia Institute of Technology" and "Welcome". spectator.co.uk sends "The Spectator" and "Home Page". facs.org sends "The American College of Surgeons | ACS" and "Home". anu.edu.au, ntu.edu.sg, hse.ie, gosh.nhs.uk, nationwidechildrens.org and patsnap.com all do a version of the same thing. The other 12 fall in the 122, because their title element also leads or ends with the same generic word: federalreserve.gov sends "Federal Reserve Board - Home" against "Home", fema.gov sends "Home | FEMA.gov" against "Home", and bundesbank.de, nice.org.uk, chop.edu, pa.gov, lu.se and ada.org follow suit.

All 29 have the same cause. A content management system is emitting the page's node title, which really is "Home", into the Open Graph block, while a separate template builds the title a human was meant to read. The result is a page that offers a title selector one good candidate and one that describes nothing. 20 of the 29 sit in the healthcare, education and government strata of this corpus, ten of them healthcare and five each education and government, which is the constituency running the largest content management systems and the one least likely to have anybody watching this field.

The remaining 74 are ordinary editorial drift, where two teams wrote two names at two different times. airbnb.com sends "Airbnb: Vacation Rentals, Cabins, Beach Houses, Unique Homes & Experiences" and an og:title of "Airbnb | Vacation rentals, cabins, beach houses, & more". allbirds.com sends "Allbirds: Comfortable, Sustainable Shoes & Apparel" and "The World’s Most Comfortable Shoes". aircanada.com sends "Book Flights Online | Air Canada" and "Air Canada - Official Website". None of those is wrong. They are just two answers to one question, published simultaneously by the same server, and Google's own documentation says it reads both. Which of the two a given surface picks is not something anybody outside the engine can observe, and the practical notes on what is and is not controllable are collected in the guide to getting cited in Google AI Overviews. A further 199 pages carried no og:title at all, 162 of which did carry a title element, so the more common state is silence rather than contradiction.

125 home pages carried no meta description, and 122 had no og:description either

The description is the weaker of the two signals by Google's own account, and the corpus treats it that way. 125 of the 1,083 pages carried no meta description element. A further 18 carried one whose content was empty. 122 pages carried neither a meta description nor an og:description, which is very nearly the same set: a page that skips one skips the other.

Where a description was present, the lengths were sane and the outliers were not. The median description ran to 149 characters. The tenth percentile was 87 and the ninetieth was 216. 35 descriptions were shorter than 50 characters and 23 were longer than 300, the longest running to 1,485 characters, which is an entire paragraph of body copy pasted into the head. 43 pages carried more than one meta description element in the same document, which is the same duplicate-template defect this blog has counted in structured data, where 117 of 612 home pages with JSON-LD carried a defect.

The title lengths are worth reporting because the folklore about them is not measurable and the distribution is. Across the 1,045 pages with a non-empty title, the median title ran to 47 characters, the tenth percentile to 15 and the ninetieth to 69, with a shortest of 2 characters and a longest of 128. 62 titles were a single word, among them "Appalshop", "Klaar", "Optifye" and, on khiry.com, the word "Store". 122 titles were two words or fewer and 191 were three or fewer. A one word title is not a defect, but it is a page that has told an answer engine its brand and nothing about what the brand does, which is the distinction entity confidence is about.

One cross-check is worth stating plainly because it cuts the other way. 221 of the 1,045 non-empty titles, 21.1 percent, did not contain the registrable label of their own hostname anywhere in the string. Some of those are honest, because a company's domain and its trading name differ. Others are pages that never say who they are in the one field every surface quotes. This run cannot tell those two apart without reading each page, so the 21.1 percent is a count of a pattern rather than a count of a fault, and it is reported here as such.

Open Graph adoption itself is high. 935 of the 1,083 pages, 86.3 percent, carried at least one og: tag, 884 carried og:title, 833 carried og:description and 579 carried og:site_name. 799 carried at least one twitter: tag. The set of tags built for social preview cards is now more consistently present than the meta description that predates it, which is a reasonable thing to know when deciding where to spend an hour on a page's head. It also lines up with the only retrieval evidence this blog has relayed on the subject: a SAGEO Arena benchmark in which rewriting the title, meta description, headings and JSON-LD moved the average retrieval hit rate from 0.58 to 0.71.

Which kinds of site sent no name, and why that is not random

The 38 nameless pages are not spread evenly across the corpus. Commerce is the worst affected, with 8 of the 66 ecommerce hostnames read sending no name, a rate of 12.1 percent. Finance follows with 7 of 95, and travel with 5 of 78. Government sent 3 of 88, healthcare 3 of 95, education 2 of 102 and news 1 of 58. The platform strata barely appear: four WordPress small business sites, and one each from Framer, Bubble, the single page app startups and the SaaS marketing set, which between them is 8 of the 385 platform-frame hosts read against 30 of the 698 read from the industry frame.

That ordering is the opposite of what a naive reading would predict, because the platform strata are exactly where you would expect a client rendered shell. The likeliest explanation, and it is an explanation rather than a measurement, is that the hosted platforms server-render the head as a matter of course while a large retailer or a large bank builds its own application and leaves the title to the client. Nothing in this run tests that, but the distribution is consistent with it, and one thing the distribution does show plainly is that size is not protection. The list of nameless hosts includes visa.com, klarna.com, nordstrom.com, patagonia.com, booking.com, agoda.com, shopee.sg, ocado.com, gymshark.com, rbc.com, zurich.com and boston.gov.

Two of the strata that did best are worth noting for the same reason. The 54 Wix and Squarespace hosts and the 31 static documentation sites read in this run produced no nameless page between them, which is a platform default doing its job. This blog has made the same observation from the other direction several times, most recently in finding that 79 of 86 Drupal robots.txt files named no AI crawler and 68 of them were Drupal's own shipped file. A default you never edit is a default that also never breaks.

The practical consequence is narrow and it is worth stating without inflation. If your home page is built as a client rendered application, the title is a server concern, not a component concern, and shipping it in the initial HTML costs one line in a template. It also sits alongside four other things a document says about its own identity, set out here as five structural signals that tell an AI who you are. The per-stack notes here cover the mechanics for React applications and for Next.js. The general form of the problem, that a document's readable content and its machine-readable labels arrive at different times, is what prose parity measures, and it is the same failure mode behind the finding that 17 of 380 home pages sent a crawler zero words. You can check a single page against this scanner's own view with what GPTBot sees, and the full method for how any of this is graded is set out in the methodology.

What this measurement does not show

No AI crawler fetched anything in this run. Every request came from LantadBot, so nothing here is evidence about what GPTBot, ClaudeBot or PerplexityBot does with a title element, and none of those vendors documents it. The one engine whose behaviour is documented is Google's, and the two pages cited above describe Search rather than any specific generative surface. Treat the Google quotations as what Google publishes about title links and snippets, and treat everything else as a description of what these 1,083 servers returned.

No JavaScript was executed, and that is the deliberate part rather than a shortcut. The question this run asks is what a crawler reading the delivered bytes is given, so the absence of a rendered comparison is a scope decision. It is also a gap: this run could not confirm that the 38 nameless pages acquire a title once a browser runs their script, because the headless browser available to this environment could not complete a TLS handshake through the network path this scan used. The reasonable inference from the 29 shells is that most of them do, and inference is not measurement, so it is written here as an inference.

Only the home page was read on each host. A site whose home page carries a good title can still ship a template that produces a blank one on every article page, and this run would never see it. Every figure is therefore a statement about home pages, and every count of a defect is a floor rather than a total. The same applies in the other direction: the 284 hosts whose home page did not answer are not missing at random, because a server that refuses an unknown crawler is likelier to refuse other automation, so the 1,083 read here are biased towards sites that are open to being read.

Each page was requested from one network location on one date. A title is a claim about 25 September 2026 and nothing after it, and the 38 nameless pages in particular are a list of what those deployments were serving that day rather than a judgement about the organisations behind them. Several are large enough that a release later the same week could change the answer. Finally, the corpus itself is an editorial sampling frame assembled for platform and industry coverage, not a random draw of the web, so every rate here supports a statement about these 1,419 hostnames and nothing wider. That constraint is the same one attached to every study on this site, and it is set out at length in the crawlability study.