Metadata & SEO Fundamentals
meta tags, Open Graph, the viewport meta tag, and favicons — the head content that determines how your page is discovered and shared.
The head Element Is Where Discoverability Lives
Everything a visitor sees renders inside <body>. But before a browser ever paints a single pixel of that body, it reads through <head> — and so does every search engine crawler, every social platform's link-preview bot, and every browser tab. The head is metadata about the page, not content of the page. Get it wrong and the page can still render perfectly for a human visitor while being nearly invisible to Google, or showing up as a blank grey box when someone pastes your link into Slack or iMessage.
This module covers the specific head content that most directly controls how your page is found and shared: character encoding and viewport declarations, the meta description search engines quote in results, Open Graph tags that power social link previews, favicons, the title tag's outsized SEO weight, and a first look at canonical links. None of this affects what a visitor sees on the page itself — all of it affects whether they ever get there.
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Riverside Pottery Studio — Handmade Ceramics in Austin, TX</title>
<meta name="description" content="Small-batch handmade pottery and wheel-throwing classes in East Austin. Studio visits by appointment, online shop ships nationwide.">
<link rel="canonical" href="https://riversidepotteryaustin.com/">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/png" href="/icon.png">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<meta property="og:title" content="Riverside Pottery Studio">
<meta property="og:description" content="Handmade ceramics and wheel-throwing classes in East Austin.">
<meta property="og:image" content="https://riversidepotteryaustin.com/og-cover.jpg">
<meta property="og:type" content="website">
</head><title>, the page still looks identical in the browser window — but it becomes far harder to find, ranks worse, and looks broken when shared. The head is invisible infrastructure, which is exactly why it is so easy to neglect.The Two meta Tags Every Page Needs Before Anything Else
You met <meta charset="UTF-8"> briefly back in the Document Structure module — it belongs here too because it is, strictly speaking, metadata about the document, and it is worth re-grounding exactly why it must be the very first thing inside <head>.
<head>
<meta charset="UTF-8">
<!-- everything else follows -->
</head>Browsers read a fixed number of bytes from the start of a document before deciding how to interpret the rest of the byte stream as characters. If charset appears after other content that includes a non-ASCII character — an accented letter, a curly quote, an emoji — the browser may have already guessed the wrong encoding for that earlier content and rendered it as garbled text (the classic "mojibake" you've likely seen as strings like ’ where an apostrophe should be). Declaring UTF-8 first, before any other head content, removes the guessing entirely.
The viewport meta tag — required for any page that should work on a phone
Without a viewport declaration, mobile browsers render the page at a fixed desktop-width "virtual viewport" — typically 980px — and then shrink the entire rendered page down to fit the phone's actual screen. The page technically loads, but every line of text is microscopic, and the user has to pinch-zoom to read anything. This single tag turns that off.
<meta name="viewport" content="width=device-width, initial-scale=1.0">width=device-width tells the browser to set the viewport width to the actual device screen width, rather than the 980px desktop default. initial-scale=1.0 sets the initial zoom level to 100% — no pre-applied shrinking. Together, these two directives are what let your CSS media queries (covered in depth in the CSS Layout phase of this track) actually respond to real device widths instead of a fictional 980px canvas.
maximum-scale=1.0, user-scalable=no to disable pinch-zoom. It was common advice years ago to "lock" the viewport this way, but it is now a well-documented accessibility failure — it prevents low-vision users from zooming in to read your content at all, and WCAG explicitly calls this out as a violation. Ship width=device-width, initial-scale=1.0 and stop there.title and meta description — What Actually Shows Up in Google
These two tags are the ones most directly responsible for how your page looks in search results — the blue clickable headline and the grey summary text underneath it.
<title>Riverside Pottery Studio — Handmade Ceramics in Austin, TX</title>
<meta name="description" content="Small-batch handmade pottery and wheel-throwing classes in East Austin. Studio visits by appointment, online shop ships nationwide."><title> is, by a wide margin, the single most heavily weighted on-page SEO signal available to you. Search engines use it both to understand what the page is about and as the literal blue link text shown in results. It also becomes the browser tab label and the default text when someone bookmarks the page. Good titles are specific, front-load the most important keyword, and stay under roughly 60 characters — longer titles get truncated with an ellipsis in Google's results, which looks unpolished and can cut off the exact phrase a user was searching for.
<!-- Weak — generic, no location, no differentiation from thousands of other "Home" pages -->
<title>Home</title>
<!-- Specific — states what the business is, what it does, and where -->
<title>Riverside Pottery Studio — Handmade Ceramics in Austin, TX</title>meta description is different in an important way: it has essentially zero direct effect on search ranking. Google has confirmed this repeatedly. What it does control is the summary snippet shown under your title in search results — and that snippet is what drives whether a person actually clicks your result over the nine others on the page. A vague or missing description means Google will auto-generate a snippet by pulling text from your page body, which is often an awkward, out-of-context sentence fragment. Aim for roughly 150–160 characters — a genuine, compelling one or two sentences, not a list of keywords crammed together.
<title> across every page of a multi-page site. Search engines treat this as a signal the pages are low-value duplicates of each other, and it actively hurts every page's individual ranking. Each page's title should describe that specific page, not the site as a whole.Keyword stuffing — an old technique that now actively backfires
Search engines in the early 2000s were relatively naive about keyword matching, which led to a now-notorious practice of cramming a title or description with repeated keyword variations. Modern search engines penalize this outright.
<!-- Do not do this -->
<title>Pottery Austin Pottery Classes Austin Pottery Studio Handmade Pottery Austin TX</title>Open Graph — Controlling How Your Link Looks When Shared
Paste a link into iMessage, Slack, X, LinkedIn, or Facebook and you get a rich preview card — a headline, a short description, and usually an image. That card is not generated from your page content by guesswork; it is built almost entirely from a set of meta tags called Open Graph tags, originally created by Facebook and now a de facto standard every major platform reads.
<meta property="og:title" content="Riverside Pottery Studio">
<meta property="og:description" content="Handmade ceramics and wheel-throwing classes in East Austin. Studio visits by appointment.">
<meta property="og:image" content="https://riversidepotteryaustin.com/og-cover.jpg">
<meta property="og:type" content="website">Notice these use property, not name — a genuinely easy detail to get wrong, since every other meta tag in this module uses name. Open Graph tags are technically part of a separate metadata protocol (RDFa) that Facebook adopted, and property is the attribute that protocol expects. Using name="og:title" instead of property="og:title" is a mistake that will not raise any visible error — the tag simply gets silently ignored by every platform that reads Open Graph data.
og:image — the tag most worth getting right
A missing or broken og:image is the single most common reason a shared link looks unfinished — most platforms will still show a card, but with a generic grey placeholder instead of your actual image, which reads as broken or untrustworthy to whoever receives the link.
<meta property="og:image" content="https://riversidepotteryaustin.com/og-cover.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">Three practical rules for og:image: the URL must be absolute (starting with https://), not a relative path — most crawlers will not resolve a relative image path against your domain the way a browser does. The image should be roughly a 1200×630 aspect ratio, which is the size nearly every platform crops to. And it must be publicly reachable without authentication — a crawler cannot log in to fetch an image sitting behind your app's auth wall.
Twitter/X Card tags — a small, optional addition
X (formerly Twitter) historically used its own separate tag namespace before largely falling back to reading Open Graph tags as well. Adding these two is low-effort and gives you an extra layer of control over how the card renders there specifically.
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Riverside Pottery Studio">
<meta name="twitter:description" content="Handmade ceramics and wheel-throwing classes in East Austin.">
<meta name="twitter:image" content="https://riversidepotteryaustin.com/og-cover.jpg">og:image often will not show up in a real share until you force a re-scrape through one of these tools.Favicons — More Formats Than You'd Expect, for Good Reason
A favicon is the small icon shown in a browser tab, bookmark list, and (on mobile) as the home-screen icon when a user "adds to home screen." A single favicon.ico file used to be enough, but modern devices expect several sizes and formats, each serving a different surface.
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/svg+xml" href="/icon.svg">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">Each line covers a different situation. favicon.ico is the long-standing fallback that essentially every browser will find automatically even with zero <link> tags at all, simply by requesting /favicon.ico from the site root — but relying on that alone means missing every modern surface below. The SVG variant scales cleanly to any size and is increasingly the preferred modern format, since one file replaces several PNG sizes. The 32×32 and 16×16 PNGs cover browser tabs and bookmark bars at their traditional pixel sizes on displays that do not support SVG favicons. apple-touch-icon is specifically what iOS uses when a user adds the page to their home screen — without it, iOS falls back to taking an ugly auto-generated screenshot of the page as the icon instead.
The web manifest — PWA-adjacent, but relevant here
site.webmanifest is a small JSON file that (among other things used for full Progressive Web App behavior, out of scope for this module) declares additional icon sizes Android uses for home-screen shortcuts and splash screens.
{
"name": "Riverside Pottery Studio",
"short_name": "Riverside Pottery",
"icons": [
{ "src": "/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png" }
],
"theme_color": "#7b61ff",
"background_color": "#ffffff",
"display": "standalone"
}realfavicongenerator.net take a single source image and output the entire set — every PNG size, the ICO, the manifest, and the exact <link> tags to paste into your head — in one pass. Most real projects use a generator rather than exporting each size manually.The Canonical Link — A Brief, Necessary Preview
It is common for the same content to be reachable at more than one URL — with and without a trailing slash, with tracking query parameters appended, or via both http and https during a migration. Search engines treat each distinct URL as a potentially separate page unless told otherwise, which can split ranking signals across duplicates instead of consolidating them onto one authoritative page.
<link rel="canonical" href="https://riversidepotteryaustin.com/classes">This single line tells search engines: "no matter which URL variant a crawler found this content at, treat this exact URL as the single authoritative version, and consolidate ranking credit there." It is especially important for pages reachable through multiple query-string combinations — a product page reachable as both /shop/mug?ref=newsletter and plain /shop/mug should canonicalize to the plain URL, so search engines don't treat the tracked link as a separate, competing page.
<link rel="canonical"> pointing at its own preferred, absolute URL — including pages that are already at their canonical URL, which should self-reference.A Marketing Launch at a Denver DTC Furniture Startup Goes Sideways
A Denver-based direct-to-consumer furniture company builds a landing page for a new sofa line and schedules a coordinated Instagram, email, and paid-social push for launch morning. The front-end engineer ships the page a day early, QAs it in a browser, and confirms it looks correct. Nobody opens DevTools to check the <head> — the marketing team assumes that's covered, the engineer assumes marketing will flag anything missing.
What goes wrong at 9am on launch day
The paid social ads go live first. Every single ad preview and every organic Instagram Story link sticker shows the same thing: a grey placeholder box where the sofa photo should be, and the fallback text "riversidefurnitureco.com" instead of the product name. The marketing lead pastes the URL into Slack to double check — same grey box there too. By the time someone traces it to a missing og:image tag, roughly 40 minutes of paid spend has run against ads showing a broken-looking preview card, and several hundred organic story views already saw the same thing with no way to fix what already rendered on a viewer's phone.
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Aurora Sofa — Riverside Furniture Co.</title>
<meta name="description" content="The Aurora sofa. Modular, machine-washable covers, ships flat-packed.">
<!-- no og:title, no og:description, no og:image at all -->
</head>The fix, and the process change that followed
The immediate fix is a two-line deploy — adding og:title, og:description, and an absolute og:image URL pointing at a properly sized 1200×630 product photo. But the fix arrives too late to matter for the ads that already ran and the story views already spent. The team's actual takeaway is procedural: every landing page destined for a paid or social push now gets pasted into Facebook's Sharing Debugger as a required step in the pre-launch checklist, specifically because a page can look completely correct in a normal browser tab while being entirely unshareable — the browser never renders Open Graph tags, so nothing about visually QA-ing the page would ever have caught this.
Four Misconceptions About Metadata and SEO
6 Interview Questions — With Complete Answers
Metadata Mistakes Teams Make Constantly
Mistake: using a relative path for og:image
<meta property="og:image" content="/images/og-cover.jpg"><meta property="og:image" content="https://riversidepotteryaustin.com/images/og-cover.jpg">Mistake: the same title tag copy-pasted across every page
<title>Riverside Furniture Co.</title><title>Aurora Sofa — Modular, Machine-Washable — Riverside Furniture Co.</title>
<title>Shipping & Returns — Riverside Furniture Co.</title>
<title>About Us — Riverside Furniture Co.</title>Mistake: locking the viewport to block pinch-zoom
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"><meta name="viewport" content="width=device-width, initial-scale=1.0">Mistake: using name= instead of property= for Open Graph tags
<meta name="og:title" content="Aurora Sofa"><meta property="og:title" content="Aurora Sofa">Mistake: forgetting apple-touch-icon
<link rel="icon" href="/favicon.ico"><link rel="icon" href="/favicon.ico">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">Bugs This Topic Produces — And Exactly Why
🎯 Key Takeaways
- ✓meta charset must be the very first line inside <head> — declaring it late risks the browser already having guessed the wrong encoding for earlier content.
- ✓The viewport meta tag (width=device-width, initial-scale=1.0) is required for a page to render at real device widths on mobile instead of a shrunk-down 980px desktop layout. Never disable pinch-zoom.
- ✓The <title> tag is the single most heavily weighted on-page SEO signal; meta description does not affect ranking but directly drives click-through rate from search results.
- ✓Every page should have its own unique, specific title and description — duplicated titles across pages read as low-value duplicate content to search engines.
- ✓Open Graph tags use property=, not name= — using name= fails silently with no error, and the tag is simply ignored by every platform.
- ✓og:image must be an absolute URL, publicly reachable without authentication, and ideally sized around 1200×630 — a broken or missing one is the most common cause of an unshareable-looking link.
- ✓Social platforms cache Open Graph data aggressively; a fix will not show up in a real share until forced through a re-scrape tool like Facebook's Sharing Debugger.
- ✓A modern favicon setup needs more than one file: an .ico fallback, PNGs for standard browser display, apple-touch-icon for iOS home screens, and manifest icons for Android.
- ✓A canonical link tag tells search engines which URL is authoritative when the same content is reachable at multiple URLs, consolidating ranking signals onto one page.
What comes next
Module 14 covers HTML entities and special characters — why & and < need escaping in text content, the entities you will actually use day to day, and exactly what breaks when you forget.
Module 14 → HTML Entities & Special CharactersDiscussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.