Title Tags, Meta Descriptions, and What Search Engines Do With Them

What Google says it does with your title, in Google's own numbers

Google's documentation on title links is unambiguous that the process is automatic. It says the creation 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, and it lists what it draws on: content in title elements, the main visual title shown on the page, heading elements such as h1, content in og:title meta tags, other content that is large and prominent through style treatments, anchor text on the page, text within links that point to the page, and WebSite structured data. Your title element is one input among eight.

The frequency is where folklore and Google disagree, and it is worth getting right before you rewrite anything. In September 2021 Google published a follow-up to its title-generation change stating that, after feedback, title elements were then used around 87% of the time, up from around 80% before. Read as a rewrite rate that is roughly 13% of results — a minority. Third-party SERP studies routinely report figures several times higher, and the discrepancy is mostly definitional: they count a trimmed brand suffix, a truncation or a swapped separator as a rewrite, where Google is describing whether the title element was used as the basis at all.

The practical reading is that a well-written, accurate, page-specific title element is used the large majority of the time, and the cases where it is replaced are the ones the documentation describes as problems: boilerplate repeated across a site, a title that does not describe the page, a language mismatch, or a title stuffed with keywords. Fixing those is the lever. Rewriting a good title because you read that Google rewrites everything is not.

The meta description, stated precisely

The usual claim is that the meta description has not been a ranking factor for many years. That is very likely true, but it is worth stating what Google actually documents rather than borrowing a sentence from the wrong tag. Google's page on the meta tags it supports says of the keywords tag that it is not used by Google Search and has no effect on indexing and ranking at all. It says no such thing about the description tag; it simply describes the description as a short description of the page which, in some situations, is used in the snippet shown in search results.

What Google does document about snippets is more useful than the ranking question anyway. Snippets, it says, are primarily created from the page content itself, and Google sometimes uses the meta description element if it might give users a more accurate description of the page than content taken directly from the page. So the description competes with your own body text for the slot, and it wins when it summarises the page better than any passage on it does. That is a writing instruction, not a technical one.

Three controls exist if you need them, and they are directives rather than hints. The nosnippet meta tag prevents a snippet being shown for the page at all; max-snippet:[number] sets a maximum length; and the data-nosnippet attribute excludes specific parts of the page from being used. Reach for those when a page contains text you do not want quoted in results, not as a substitute for writing a better description.

Truncation is by pixel width, not character count

Google documents no character limit for either element. On the meta description it says plainly that there is no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width; the title-link page uses the same formula. That last clause is the whole answer. Fitting a width is a typographic operation, and in a proportional typeface the width of a string is the sum of its glyph advances, which have nothing to do with how many characters there are.

How far apart can those advances be? In Arial at 20 pixels, a lowercase i is 4.4434 px wide and a capital W is 18.8770 px — a factor of 4.25. A lowercase m is 16.6602 px, and a space is 5.5566 px. Sixty characters of the letter i render 266.60 px wide; sixty of the letter W render 1,132.62 px. A 600-pixel container therefore holds 135 letter i, or 31 letter W. Any rule expressed in characters is being applied to a quantity that varies by a factor of four.

The measurements in this article use Arial at 20 pixels in a 600-pixel container, and that is a stated assumption rather than a documented fact. Google publishes neither the typeface nor the container width, both have changed over the years, and the rendered width differs between desktop and mobile and between operating systems. What does not change is the mechanism: the cut happens at a width, so measure your titles in whatever face your own audience actually sees rather than counting characters.

Two titles of exactly sixty characters, one of which does not survive

Take two plausible titles built from ordinary English words. The first is "Illinois Title Filing Limits: Tips, Lists and Little Filings" and the second is "Womenswear Warehouse Awards: Common Womenswear Brands Ranked". Both are exactly 60 characters long, including spaces and punctuation. Any character-counting tool grades them identically.

Rendered in Arial at 20 pixels they are not remotely the same. The first measures 461.26 px, an average of 7.69 px per character. The second measures 665.81 px, an average of 11.10 px per character. The gap is 204.55 px, which makes the second title 44.35% wider than the first at identical length. In a 600-pixel container the first fits whole with 138 px to spare, and the second does not fit at all.

Where exactly does the second one break? An ellipsis in Arial at 20 pixels is itself 20.00 px wide, so allowing for it leaves 580 px of text, which holds 51 characters — the title is cut at "Womenswear Warehouse Awards: Common Womenswear Bran". Cut instead at the last whole word that fits, it keeps 46 characters and 522.39 px: "Womenswear Warehouse Awards: Common Womenswear". Either way the words "Brands Ranked" — the two that say what the page is — never reach the screen. And the density difference is not a rounding matter: at the first title's density 78 characters fit in 600 px, and at the second's only 54.

Front-load, because truncation always eats the end

The rule follows from the mechanism rather than from taste. Truncation removes a suffix, so whatever you put last is what you are volunteering to lose. Rearrange the second title so that its subject leads — "Womenswear Brands Ranked: Common Warehouse Awards Compared" — and at 58 characters it still measures 636.93 px and is still cut, this time after 52 characters. But the cut now lands on "Womenswear Brands Ranked: Common Warehouse Awards Co", so the three words that say what the page is have survived and only a qualifier is lost.

Two corollaries. Put the brand suffix at the end if you use one at all, because that is the position designed to be sacrificed, and Google's documentation lists boilerplate repeated across a site as one of the things that prompts it to generate its own title. And remember that the title link is written for a person deciding whether to click: it is read at speed, in a column of nine competing results, by someone who will never see the part you truncated.

Open Graph and card tags are a different system with different consumers

The og: tags are not search-engine tags. They belong to the Open Graph protocol, and their consumers are the link-preview parsers of social networks, chat apps and messaging clients — the thing that decides what your URL looks like when someone pastes it into a group chat. That is a completely different surface from a search result, with a different reader in a different frame of mind, and there is no reason the same sentence should serve both.

There is one crossover worth knowing, and Google states it: og:title is one of the sources Google draws on when generating a title link. So an og:title that contradicts your title element is not harmless — it is another candidate you have handed to the generator. Card tags in the twitter: namespace are a third layer, historically consumed by one platform and designed to fall back to the Open Graph equivalents when absent, which is why omitting them is usually safer than filling them with a third variant of the same sentence.

What the canonical tag actually does

The canonical tag is often filed with the title and description as though it were part of the same job. It is not. Its role is duplicate consolidation: when several URLs serve the same or very similar content, it tells Google which one you would like treated as the representative version. It has nothing to say about what appears as your title link or your snippet.

It is also weaker than most people assume. Google describes rel=canonical as a strong signal that the specified URL should become canonical — a signal, not a directive — and it lists other inputs it weighs alongside it, preferring HTTPS pages over equivalent HTTP ones and preferring URLs that are part of hreflang clusters. When you express no preference, Google says it identifies which version of the URL is objectively the best version to show to users. So a canonical that points somewhere the rest of your signals contradict is a suggestion that can be overruled, and the fix is to make the signals agree rather than to repeat the tag more emphatically.

Frequently asked questions

How often does Google actually rewrite title tags?

Google's own published figure, from its September 2021 Search Central post on title generation, is that title elements are used around 87% of the time, up from around 80% before that change — which reads as a rewrite rate of roughly 13%. Third-party SERP studies report much higher numbers because they count truncation, brand-suffix trimming and separator changes as rewrites. Take Google's figure as the answer to whether your title was used as the basis, and the third-party figures as the answer to whether it appeared verbatim.

Is the meta description a ranking factor?

Google has never documented it as one. Be careful with the usual proof, though: the explicit sentence stating that a tag is not used by Google Search and has no effect on indexing and ranking at all appears in Google's documentation about the keywords meta tag, not the description. What Google does document about the description is that it is a short summary of the page which is sometimes used in the snippet, and that snippets are primarily created from the page content itself. Treat it as a click-through instrument, and write it as one.

How many characters should a title be?

The question has no fixed answer because the constraint is width, not count. Google documents no character limit and says only that titles and snippets are truncated as needed, typically to fit the device width. Measured in Arial at 20 pixels, two real 60-character titles came out at 461.26 px and 665.81 px — 44.35% apart — and only the first fits a 600-pixel container. At the first title's density 78 characters fit; at the second's, 54. Measure the string, do not count it.

Do I need Open Graph tags if I already have a title and description?

They serve a different surface: link previews in social networks, chat apps and messaging clients, which is a different reader in a different context from a search result. Add them when shared links matter to you, and write them for that context rather than pasting the search title in. One caution: Google lists og:title among the sources it draws on when generating a title link, so an og:title that contradicts your title element hands the generator an extra candidate. Card tags in the twitter: namespace fall back to the Open Graph equivalents, so omitting them is usually safer than adding a third variant.

Will a canonical tag force Google to show the URL I choose?

No. Google describes rel=canonical as a strong signal that the specified URL should become canonical, and a signal is not a directive. Google weighs other inputs alongside it — it prefers HTTPS pages over equivalent HTTP ones and prefers URLs that are part of hreflang clusters — and where you express no preference it says it identifies which version of the URL is objectively the best to show users. If your canonical is being ignored, the productive move is to align the conflicting signals, including internal links, sitemaps and redirects, rather than restating the tag.