Title tag: 21 of 1,061 home pages gave an AI crawler no name, and 14 named a block page

What the title tag is for, and why a citation is its hardest case

Three sentences in the HTML Living Standard do all the work here, and they are worth reading in order. The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. And then, immediately after: the document's title is often different from its first heading, since the first heading does not have to stand alone when taken out of context.

That third sentence matters more than it looks, because it is the specification saying in advance that a title and an h1 are allowed to differ, and saying why. A heading sits inside a page that explains it. A title gets quoted somewhere the page is not. So a run that found titles and headings disagreeing would not have found a defect, and this one did find exactly that: on 704 of the 755 pages carrying both, the first h1 and the title were not the same string. That is the expected shape rather than a problem, and it is a different question from whether a page declares heading structure at all, or declares more than one h1.

The reason to measure titles for AI visibility rather than for search results is that an assistant's citation is the out of context case taken to its limit. A search result still shows a snippet, a URL and a domain. A line in a generated answer often shows a name and nothing else. MDN's reference for the title element, last modified 24 April 2026, puts the usability half of this plainly: it says titles should be unique to every page of a website, ideally surfacing the primary purpose of the page first, followed by the name of the website, and that it is important to provide an accurate and concise title to describe the page's purpose. Nothing in that advice changes for a machine reader. What changes is that the machine has less around the title to recover from a bad one.

Does the title tag matter for AI search? One publisher documents it and three do not

Only one of the four organisations whose crawlers this product tracks has published how it picks a page's name, and it is the search engine rather than any of the assistants. Google's title link documentation, carrying Last updated 2025-12-10 UTC, says generation of title links is completely automated and takes into account both the content of a page and references to it that appear on the web, then lists nine sources it uses: 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.

Four of those nine sit in the markup of the page itself, which is what made this measurable: the title element, headings, og:title and structured data. The same page also tells authors what not to do, in words worth keeping: make sure every page on your site has a title specified in the title element, avoid vague descriptors like Home for your home page, and avoid repeated or boilerplate text in title elements. On length it declines to give a number, saying only that there is no limit on how long a title element can be and that the title link is truncated in Google Search results as needed, typically to fit the device width.

Set that against the three assistant vendors. OpenAI's crawler overview documents GPTBot, OAI-SearchBot, OAI-AdsBot and ChatGPT-User. Anthropic's crawler article documents ClaudeBot, Claude-User and Claude-SearchBot. Perplexity's crawler page documents PerplexityBot and Perplexity-User and spends most of its length on robots.txt and firewall configuration. Read at source on 8 November 2026, none of the three mentions the title element, headings, og:title or structured data at all. That is a statement about those documents and not about those crawlers: absence of a published rule is recorded here as absence, the same way it was recorded when this blog read the nine vendor pages behind its crawler registry and found the word noindex in two of them. If you want to know which of your pages a given crawler can reach before worrying what it calls them, the crawler tokens we track and the robots.txt tester answer that first question.

21 pages handed a crawler no readable name

Of the 1,061 home pages that answered with HTTP 200 and an HTML content type, 1,040 delivered a title with text in it. The other 21 split two ways: 16 carried no title element anywhere in the document, and 5 carried one that was empty. Every one of the 21 was requested again about twenty minutes later and every one behaved the same way, so none of this is a single unlucky fetch.

The 21 are two different stories wearing the same result, and the byte count separates them cleanly. Ten of them answered with 1,158 bytes or fewer, which is not a page at all. Four of those are redirect stubs carrying a meta refresh, the mechanism this blog measured when it found 14 of 1,069 home pages using one, and irishrail.ie is 92 bytes of exactly that and nothing else. Six more are bot mitigation shells that pair a robots noindex with a script the crawler cannot run, among them statssa.gov.za, gtbank.com and zurich.com at 212 bytes each. A shell has no title because it has no content to name, which is a fair description of the response rather than a fault in it.

The other eleven are the interesting half, because they are documents rather than stubs. Six carried no title element at all while running from 21,471 bytes on sj.se to 715,468 on aboutyou.de, and five carried a title element with nothing inside it, from 3,235 bytes on sundhed.dk to 869,110 on medscape.com. Five of the eleven delivered zero words of prose as well as no name, those being sundhed.dk, sj.se, shopee.sg, agoda.com and nordstrom.com, which puts them alongside the pattern behind 11 of 271 pages returning no words at all: the document is a container and the text, title included, arrives later from script. gymshark.com is the sharpest single case, at 57,414 bytes carrying one word of prose and no title element. A crawler that executes JavaScript may well resolve all of this. One that does not, and two of nine assistants tested did not, is left with a document it cannot name.

Nothing in that set is evenly spread. 20 of the 21 sit in the eight industry strata and only one in the ten platform strata, with ecommerce carrying 5, travel 4 and finance 4. That is direction rather than a rate, because the corpus is a sampling frame rather than a census, and the platform strata are smaller.

14 titles named a block page, every one with HTTP 200

A missing name is a gap. A wrong name is worse, because it looks like an answer. 14 of the 1,040 titles did not name a website at all: they named the thing standing in front of it. Twelve read One moment, please, with a trailing ellipsis, nocodemvp.com read 403 Forbidden and lowes.com read Access Denied.

The status code is the part that should bother anyone measuring this. All 14 responses were HTTP 200. A crawler that keys on the status line has no reason to treat any of them as a refusal, so the interstitial is not recorded as a block, it is recorded as the page, and the page is called One moment, please. This is the same failure mode as a soft 404, where 125 of 1,094 sites answered 200 for a page that did not exist, and it is distinct from the clean refusals in the same run: 224 hosts answered the home page with a 403, which is at least honest, and sits with the 103 of 1,089 pages a CDN closed in an earlier pass.

The twelve One moment pages are one product rather than twelve decisions. Eleven of them landed between 11,961 and 12,210 bytes with eleven words of prose, which is a single template, and they are concentrated where you would expect a managed security plugin: seven in the WordPress small business stratum, two in the local media stratum, one on Framer, one in the no code app stratum and one in healthcare, at inserm.fr. All 14 served the same title again on the confirmation pass. One of them, etnhvac.com, returned its own title, East Tennessee HVAC and Plumbing, to a request in between, so on that host the interstitial is intermittent rather than permanent. That is worth stating precisely, because it is the difference between a site that cannot be read and a site that cannot be relied on to be readable, and only the second one is invisible to a single scan.

Lantad is built to refuse to grade this situation rather than score it, which is the argument in why we withhold a grade. A page whose name is Access Denied has not been measured. It has been intercepted, and the honest report says so.

When the title, the og:title and the structured data disagree

Four of Google's nine title link sources sit in the markup, and adding twitter:title, which Google does not name, makes five places where a page can state what it is called. Most pages used more than one of them and not all five: counting distinct normalised strings across the title, og:title, twitter:title, a page level JSON-LD name and the first h1, 229 of the 1,040 pages offered exactly one name, 492 offered two, 282 offered three, 35 offered four and 2 offered five.

Most of that spread is not disagreement in any meaningful sense. 872 pages declared an og:title and 654 of those matched the title exactly once whitespace and case are normalised. On another 125 one string contained the other, which is almost always the brand suffix being dropped: nisolo.com titles itself Ethically Made Shoes and Accessories with its name appended and sets og:title to the same phrase without it. That leaves 93 pages, 10.7 percent of the 872, where the two strings share no containment relationship at all. povio.com pairs a title about product design and development with an og:title that reads Build, Ship, and Scale with Povio. letterhunt.co pairs the title LetterHunt with an og:title of lh-JBSSJK, which looks like an internal identifier that escaped. These are the cases where the answer to what is this page called has two defensible answers and a machine picks one.

The JSON-LD figure looks much worse and mostly is not. A page level name was present on 423 pages and differed from the title on 293 of them, but 302 of the 423 came from a WebSite node, and 258 of the 293 differences did too. schema.org defines WebSite as a set of related web pages served from a single web domain, and name on it is inherited from Thing as the name of the item, so on a WebSite node the correct value is the name of the site, not of the page. A site called KOHA Pet whose home page is titled for its product range is describing both things accurately. The honest residue is the 107 names that came from a WebPage node, where the value does refer to the page: 26 of those differed from the title. That is a tenth of a much smaller number, and it sits beside the finding that 158 of 338 sites connected neither of their WebSite and Organization nodes to anything.

Two small things are worth recording because they are cheap to fix and silently wrong. Three pages left an HTML entity undecoded inside a title or og:title, so botanicapaper.com ships an ampersand entity as literal text where an ampersand belongs, the same class of defect as the 15 of 1,088 pages declaring no character encoding. And ten pages wrote og:title into a name attribute rather than the property attribute the protocol uses, which an earlier pass over the Open Graph block found on 27 of 1,135 pages for og properties generally.

Short titles, duplicate title elements, and a coincidence worth naming

Length first, because it is the thing most often asserted without a number. The 1,040 titles ran from 2 characters to 126, with a median of 46. 208 were longer than 60 characters, which is the point MDN says search engines typically begin cutting, giving the range as 55 to 60 characters. 118 were 15 characters or shorter. Google declines to set a limit and says only that the title link is truncated as needed, so the 60 character figure describes a display behaviour in one product rather than a rule about what a crawler reads. An assistant quoting a name is not constrained by a result layout at all.

Shortness does more damage than length here. Two pages titled themselves with a bare generic word, esa.int as Homepage and hku.hk as index, which is the class of title Google's documentation asks authors to avoid when it names Home as a vague descriptor. 70 more titled themselves with nothing but the brand or the domain, so featherhaus.com is called Featherhaus and soilboy.sg is called Soilboy. That is not wrong, and for a one page site it may be the whole truth, but a name that carries no subject gives an answer engine nothing to match a question against, which is the gap the entity work on this site exists to measure.

A separate 70 pages are the ones where the title is the only name declared anywhere: no og:title, no twitter:title, no JSON-LD name and no h1. The two counts landing on 70 is a coincidence and they are not the same pages, with only nine appearing in both. It is worth saying so out loud rather than quietly printing two seventies and letting a reader assume one of them is a typo.

Finally, ten pages carried more than one document level title element, against the specification's instruction that there must be no more than one per document. uhn.ca carried four, one with text and three empty. The cause is usually a third party widget bringing its own head content along: fullsteamcrossfit.com's second title reads Wodify Iframe, magicalkenya.com's reads Typebot Chat Widget, and unilag.edu.ng's reads Air Quality Map. variety.com carried two with identical wording where the second writes its dash as an HTML entity. Which one a parser takes is undefined by the markup, so a page in this state has handed the decision to whichever crawler is reading, and that is the same category of problem as the stray meta elements that address nobody.

What to check on your own site

The sequence is short and none of it needs a tool. Fetch your own page the way a crawler does, with no JavaScript, and read what came back rather than what you believe is there. What GPTBot sees does the fetch for you and shows the delivered HTML, and it is the step that catches every failure in this post, because all of them are visible in the first response.

Then ask four questions of that response, in order of how much they cost you. Is there exactly one title element with text in it. Does that text name the page rather than the interception in front of it, which means checking the status line and the title agree about what happened. Does the title say what the page is about and not only who published it. And do the og:title and any page level JSON-LD name say the same thing the title does, or differ for a reason you could defend. Where they differ without a reason, pick one and make the others follow it, since nothing downstream can resolve a disagreement the page itself did not.

One thing is deliberately not on that list: an instruction to pad titles to a character count. The evidence here does not support it. The median title in the corpus is 46 characters and the problems found are at the edges, in the 21 pages with no name and the 14 naming a block, not in the middle of the distribution. If a stack is the reason a title never reaches the first response, the fix belongs in the stack rather than in the copy, which is what the per stack guides for Next.js and Shopify are for, and how Lantad scores a page explains where a name sits among the signals that decide whether an assistant can use your page at all.