seo
Every HTML Meta Tag That Matters for SEO (and the Ones Google Ignores)
The head tags that change indexing or how your result looks, the robots directives Google honors, the tags it ignores, and the canonical edge cases that bite.
A typical <head> collects tags over the years. Some came from a plugin, some from a 2011 tutorial, and nobody remembers which ones matter. Only a handful of head tags change whether Google indexes a page or how its result looks, and Google says in writing that it ignores the rest. Below is that short list, checked against Google Search Central’s list of supported meta tags, its robots meta tag reference and its canonicalization docs.
To see what a live page actually ships, paste its URL into our Meta Tag Analyzer. It reads the title, description, canonical, viewport, charset, robots and googlebot meta, and the Open Graph and Twitter tags, then flags missing basics like the title, description, canonical, viewport and core OG tags.
The tags that change something
| Tag | What Google does with it | Affects ranking? |
|---|---|---|
<title> | Main source for the title link in results, but Google also looks at headings, anchor text and other prominent text | Google doesn’t say. Write it as if it does, since it’s what searchers see first |
<meta name="description"> | Snippet source, used only when it describes the page better than the page text does | No, display only |
<meta name="robots"> / googlebot | Indexing and snippet rules (full list below) | Controls whether you appear at all |
X-Robots-Tag header | Same rules as the robots meta, sent as an HTTP header | Same as above |
<link rel="canonical"> | A strong signal for which duplicate URL to show (“a hint, not a rule”) | Consolidates signals onto one URL |
<meta name="viewport"> | Google says its presence indicates the page is mobile friendly | Indirectly |
<meta charset="utf-8"> | Tells the parser how to decode bytes | No, but broken encoding breaks everything |
<link rel="alternate" hreflang> | Points users to the right language or region version | No, it swaps which URL is shown |
og:*, twitter:* | Built for social platforms and chat apps; Google reads og:image as a preferred-image hint and og:site_name for site names | No, display only |
<meta name="theme-color"> | Not on Google’s supported list; browsers may tint their UI | No |
A few notes on the rows that people get wrong.
Title. Google’s title link doc says there’s no limit on how long a <title> can be. The title link is truncated as needed, typically to fit the device width, so the real limit is pixels, not characters. “50 to 60 characters” is a rule of thumb for fitting that width on desktop, not a Google rule. Our analyzer warns past 60 characters for that reason. Make each title unique, and skip boilerplate that only changes one word per page.
Description. The snippet doc says snippets are “primarily created from the page content itself.” Google uses your meta description only when it gives a more accurate summary. A good one is still worth writing, because it’s the text you control when Google does use it. There’s no length limit there either. It’s truncated to fit.
Viewport and charset. Use width=device-width, initial-scale=1 and leave zoom enabled. The HTML spec requires the charset declaration to sit completely within the first 1024 bytes of the document, so make <meta charset="utf-8"> the first thing in <head>.
Open Graph. These tags decide how a link looks when it’s pasted into Slack, LinkedIn or iMessage. They don’t change how you rank. Google does read two of them for display: og:image is one way to suggest the image shown next to your result or in Discover, and og:site_name is one input to the site name above it. The sizes, the tags you need and the debugging steps are in the Open Graph image guide, and you can render the cards before shipping with the OG card preview.
hreflang. Every version has to list itself and all the others, using fully qualified URLs. The traps are covered in the hreflang mistakes post.
The robots directives Google actually honors
Default is index, follow. You never need to write all. These are the rules Google documents:
| Directive | Effect |
|---|---|
noindex | Don’t show this page in results |
nofollow | Don’t follow the links on this page |
none | Same as noindex, nofollow |
nosnippet | No text snippet or video preview (a static thumbnail may still show) |
max-snippet:[n] | Snippet of at most n characters; 0 means none, -1 lets Google choose |
max-image-preview:[none|standard|large] | Largest image preview allowed |
max-video-preview:[n] | Video preview of at most n seconds; 0 allows a static image only, -1 means no limit |
notranslate | Don’t offer a translation of this page in results |
noimageindex | Don’t index images on this page |
unavailable_after:[date] | Drop the page from results after this date |
indexifembedded | Allow indexing when embedded in an iframe, despite noindex (only works alongside noindex) |
noarchive is retired. Google says it “is no longer used by Google Search to control whether a cached link is shown.” Leaving it in does no harm.
Three rules decide what happens when tags pile up:
- The most restrictive rule wins.
<meta name="robots" content="index">plus<meta name="googlebot" content="noindex">means noindex for Google. - Case doesn’t matter in the meta tag’s name or content, or in the header.
google-site-verificationis the one exception: its values must match exactly. - Google has to crawl the page to see any of it. A URL blocked in robots.txt never shows Google its
noindex, so the URL can stay indexed from links alone. That trap gets its own post: what robots.txt actually controls.
X-Robots-Tag: the same rules, as a header
Google’s doc puts it plainly: “Any rule that can be used in a robots meta tag can also be specified as an X-Robots-Tag.” The header is the only option for files that have no <head>, like PDFs, images and JSON:
X-Robots-Tag: noindex
X-Robots-Tag: googlebot: nofollow
X-Robots-Tag: max-image-preview:large, max-snippet:160You can send several headers or join rules with commas. A user-agent prefix like googlebot: scopes the rule to that crawler. The header never shows up in View Source, which is why a forgotten noindex on a staging server so often makes it to production. Check the actual response with the HTTP header analyzer.
The tags Google ignores
Google’s supported-tags page says: “You can use other meta tags if they are important to your site, but Google will ignore meta tags that it doesn’t support.” The first four below it calls out by name. The rest simply aren’t on its list:
| Tag | Status |
|---|---|
<meta name="keywords"> | ”not used by Google Search, and it has no effect on indexing and ranking at all” |
<link rel="next"> / rel="prev" | ”Google no longer uses these HTML <link> tags” |
<html lang> | Not used for language detection; Google reads the page text |
nositelinkssearchbox | ”no longer used by Google Search” (the sitelinks search box is gone) |
<meta name="revisit-after"> | Not on Google’s supported list; recrawl timing is Google’s call |
<meta name="author"> | A valid HTML name, but not on Google’s list. It doesn’t affect ranking |
<meta name="title"> | Not on Google’s list. The <title> element is what counts |
Keep <html lang> anyway. Screen readers use it to pick a voice and pronunciation. Keep author if your CMS wants it. Neither one helps or hurts in Search.
For bylines that do show up in results, use author in your Article structured data, as in the JSON-LD guide.
Canonical edge cases
The basic tag is one line in <head>:
<link rel="canonical" href="https://example.com/shoes/red-sneakers">Google’s canonicalization overview calls a canonical preference “a hint, not a rule.” Google can still pick a different URL. It also says none of the canonicalization methods are required. Things go wrong at the edges.
Self-referencing. Pointing a page’s canonical at itself is fine, and it’s the cheapest way to stop ?utm_source= or ?gclid= copies from splitting your signals (why UTM tags matter here). Use an absolute URL. Google supports relative paths but recommends absolute ones. The tag only counts in <head>. Don’t use a URL with a #fragment as the canonical; Google says not to.
Cross-domain. A canonical can point at another domain. For content you syndicate to partners, though, Google’s canonicalization troubleshooting page says the canonical link element “is not recommended,” because the partner’s pages are often very different from yours. Ask partners to block indexing of their copy (a noindex) instead.
Canonical plus noindex. Don’t. noindex says “drop this URL,” while the canonical says “pass this URL’s signals somewhere else.” Google says it doesn’t recommend noindex for choosing a canonical within a site, “because it will completely block the page from Search.” For a duplicate, use the canonical alone. For a page that should vanish, use noindex alone.
Paginated pages. Google’s pagination guide says: “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.” Page 3 has different products than page 1, so canonicalizing it to page 1 hides those products. As noted above, rel="next" and rel="prev" no longer help with Google.
HTTP vs HTTPS. Google prefers HTTPS as the canonical unless something is broken, like an invalid certificate or an HTTPS page that redirects to HTTP (which redirect code to use). Still, make every signal agree. Canonical tags, sitemap entries, hreflang URLs and internal links should all use the https:// version, and http:// should 301 to it. Google warns against giving different canonicals through different methods. Check the redirect hops with the redirect checker.
Non-HTML files. A PDF can declare its canonical with an HTTP header: Link: <https://example.com/white-paper.pdf>; rel="canonical". Pick either the header or the HTML tag for a page, not both. Google says using both “is more error prone.”
A minimal head that covers it
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Red Sneakers, Sizes 5 to 13 | Example Shoes</title>
<meta name="description" content="Canvas red sneakers with a gum sole. Free returns within 30 days.">
<link rel="canonical" href="https://example.com/shoes/red-sneakers">
<meta property="og:title" content="Red Sneakers | Example Shoes">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/shoes/red-sneakers">
<meta property="og:image" content="https://example.com/og/red-sneakers.png">
<meta name="twitter:card" content="summary_large_image">Those four og: lines are the ones the Open Graph protocol marks as required. Add a robots meta only when you need to restrict something. Add hreflang only if you have language versions.
The meta tag generator builds the title, description, canonical, viewport, robots, Open Graph and Twitter Card lines from a form. Then run the live URL through the SEO analyzer. It checks the same tags, flags a noindex (or none) in the robots or googlebot meta or the X-Robots-Tag header, and checks whether the canonical points back at the page itself. For a wider audit beyond the head, the on-page SEO checklist has the rest.