016: SEO Basics and Head Metadata
Learning outcomes
By the end of this lesson, you can write a meta description and social-preview tags that describe your actual page content; add a favicon and canonical URL correctly; explain what HTML can and cannot do for search ranking; and audit your own portfolio and Rina's Kitchen site for metadata that misrepresents what a visitor will find.
Prerequisites and retrieval
Bring the finished, semantic multi-page site from lessons 002–014. Before reading on, explain in your own words why <title> matters to both a browser tab and a search results page — you met this fact in lesson 002, and today builds directly on it. Recall from lesson 001 that a server response carries headers in addition to HTML bytes; some of today's metadata duplicates information a server header could also send, and you should know which one wins.
Terminology
- SEO (Search Engine Optimization): Practices that help a page be found, correctly understood, and fairly represented by search engines. — Source: MDN: SEO for developers
- Meta description: "A summary of a page's content that some search engines use in search results." — Source: MDN: The meta element — description
- Canonical URL: The
link rel="canonical"element identifies the preferred URL among duplicate or near-duplicate pages. — Source: MDN: rel=canonical - Favicon: The small icon associated with a page or site, declared with
link rel="icon". — Source: MDN: Favicon - Open Graph: A protocol of
meta property="og:*"tags that social platforms read to build link preview cards. — Source: Open Graph Protocol - Structured data: Machine-readable data (commonly JSON-LD) embedded in a page describing its content in a shared vocabulary. — Source: MDN: Understanding structured data
- Crawler: An automated program, such as a search engine's, that requests and reads pages to index them. — Source: MDN: Introduction to SEO
- robots meta tag:
<meta name="robots" content="...">gives per-page crawling/indexing hints to compliant crawlers. — Source: Google Search Central: Robots meta tag - Semantic SEO: The idea that correct heading hierarchy, landmarks, and link text (lessons 003–006) are themselves ranking-relevant signals, not just accessibility signals. — Source: MDN: SEO for developers
Mental model: metadata is a promise you must keep
Everything you write in head is a claim about the page that something other than a human reading the body text will trust: a browser tab, a search results snippet, a chat app's link preview card, or an automated crawler. None of these readers render your CSS or run your JavaScript before forming a first impression. If your title says "Rina's Kitchen — Fresh Sourdough Daily" but the page is actually about hiring, you have not tricked a search engine — you have wasted a visitor's trust the moment they click through and find a mismatch, which search engines increasingly detect and penalize anyway.
Treat every tag in this lesson as a summary contract: write it after the page content exists, derive it from that content, and keep it in sync whenever the content changes. Never write metadata first and content to match it later.
You already did most of the real SEO work in earlier lessons without calling it that. A logical heading hierarchy (003), meaningful link text instead of "click here" (004), context-appropriate alt text (005), and correct semantic landmarks (006) are all read by crawlers, not only by assistive technology. Today adds the small remaining layer that lives specifically in head.
Description, canonical, and favicon
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Sourdough & Pastries | Rina's Kitchen, Baker Street</title>
<meta name="description" content="Rina's Kitchen bakes sourdough and pastries fresh every morning on Baker Street. See today's menu, opening hours, and order a custom cake.">
<link rel="canonical" href="https://rinaskitchen.example/">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon.ico" sizes="32x32">
</head>
Write the description as one or two genuine sentences, roughly 120–160 characters, that a human would actually want to read before clicking. It is not a keyword list; stuffing it with repeated terms ("bakery, bakery near me, best bakery") is both unhelpful to readers and against most search engines' guidelines. Search engines may still choose to display a different snippet pulled from your body text if they judge it more relevant to a particular search — your description is a strong suggestion, not a guarantee.
rel="canonical" matters once a page is reachable by more than one URL — with and without a trailing slash, or with a tracking query string appended. Point it at the one URL you want indexed, using an absolute URL. Without it, search engines may split ranking signals across what they see as several separate near-duplicate pages.
A favicon is not cosmetic decoration you can skip: browsers use it in tabs, bookmarks, and history, and its absence is one of the fastest ways a site looks unfinished. Provide an SVG for crisp modern rendering and a fallback .ico for older support, both referenced from every page — not only index.html.
Indexing directives and language signals
A canonical URL tells crawlers which duplicate or near-duplicate URL you prefer. It does not itself block indexing. When a page should not appear in search results, an indexing directive is a different tool:
<meta name="robots" content="noindex, nofollow">
Use noindex deliberately—for staging pages, private-but-publicly-reachable previews, or duplicate utility pages where indexing would be harmful. Do not add it to production templates casually; a single copied directive can remove an entire site from search results.
robots.txt and <meta name="robots"> also solve different problems. robots.txt can control crawling behavior, while noindex is an indexing instruction discovered from the page or an HTTP header. Blocking a crawler from fetching a URL can prevent it from seeing the page-level noindex directive.
The document language from lesson 002 is also metadata:
<html lang="en">
Set it correctly on every page. If a passage changes language, use lang on that passage. Search, translation, speech synthesis, and browser language tooling all benefit from accurate language information.
Guided example: give Rina's homepage real metadata
Recall the finished index.html you built for Rina's Kitchen across lessons 002–013. Its head currently has only charset, viewport, and title. Extend it honestly:
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Home | Rina's Kitchen</title>
<meta name="description" content="Fresh sourdough and pastries baked every morning at Rina's Kitchen on Baker Street. Check today's menu, opening hours, and order a custom cake ahead.">
<link rel="canonical" href="https://rinaskitchen.example/">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
</head>
Read your own description back against the actual main content on the page. Does it mention the opening-hours table from lesson 007? Does it mention the cake-order form from lesson 009? If you wrote "the best bakery in town" instead, delete it — that is a subjective claim, not a summary, and it tells a visitor nothing they can act on. A useful test: could a stranger decide whether to click through based only on this sentence, without having seen the page?
Now do the same for order.html. Its title and description must differ from Home's — "Order a Custom Cake | Rina's Kitchen" and a description that mentions sizes and pickup dates, not opening hours. Copying Home's metadata to every page is the most common defect this lesson exists to catch; it is the metadata equivalent of the copied aria-current mistake from lesson 012.
Social previews with Open Graph
When someone pastes a link to Rina's site into a chat app, the preview card it builds usually comes from Open Graph tags, not from your description alone:
<meta property="og:title" content="Rina's Kitchen — Fresh Sourdough Daily">
<meta property="og:description" content="Fresh sourdough and pastries baked every morning on Baker Street. Order a custom cake ahead of time.">
<meta property="og:image" content="https://rinaskitchen.example/images/storefront-share.webp">
<meta property="og:url" content="https://rinaskitchen.example/">
<meta property="og:type" content="website">
og:image needs an absolute URL, because the platform generating the preview fetches it independently of the page — a relative path resolved against nothing will simply fail silently, leaving a blank or default preview image. Choose an image that makes sense cropped square or wide, since you do not control how each platform crops it; the storefront photo from lesson 005 is a better choice here than a screenshot full of small text.
These tags duplicate rather than replace title and meta description — keep them consistent with each other rather than writing three different summaries of the same page.
Intermediate example: robots and structured data, used carefully
Some pages should not be indexed at all — a staging copy of Rina's site, or an internal draft:
<meta name="robots" content="noindex, nofollow">
Apply this only where you genuinely mean it. Placing noindex on a real page by accident, or forgetting to remove it once a staging page goes live, silently removes a page from search results with no visible error in your browser — a defect you can only catch by checking the head directly, which is exactly why lesson 014's baseline checklist is worth extending to include a metadata pass.
Structured data goes further than meta tags by describing your content in a shared vocabulary a crawler can parse programmatically, commonly as JSON-LD inside a script tag:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Bakery",
"name": "Rina's Kitchen",
"url": "https://rinaskitchen.example/",
"openingHours": "Mo-Fr 07:00-18:00, Sa 08:00-14:00"
}
</script>
This is optional enrichment, not a replacement for the semantic HTML you already wrote. A search engine that cannot parse your JSON-LD for any reason should still be able to understand Rina's opening hours from the real table you built in lesson 007 — structured data is a bonus signal layered on top of correct HTML, never a substitute for it.
Advanced optional extension: what metadata cannot do
No meta tag can compensate for content that does not exist, load slowly, or excludes real users. A description promising "the most accessible bakery site" does not make keyboard navigation work if lesson 011's audit was skipped. A perfect Open Graph card does not fix a 404 behind it. Ranking algorithms also weigh signals entirely outside HTML's control — inbound links from other sites, load performance, and mobile usability among them — that this course does not claim to teach.
Treat this lesson's tags as the last five percent of a page that already has meaningful headings, honest link text, real alt text, and working forms. Applied to a page that skipped those earlier lessons, better metadata mostly succeeds at bringing more visitors to a broken experience faster.
Common mistakes and debugging
- Keyword-stuffed description: write one honest sentence a human would want to read, not a term list.
- Identical title/description copied across pages: every page needs a summary specific to its content.
og:imagegiven a relative path: platforms fetch it independently; use an absolute URL.- Forgotten favicon: every page should reference one, not only the homepage.
noindexleft on a page after launch: checkheaddirectly; the browser gives no visible warning.- Structured data duplicating false information: JSON-LD must match the real, visible page content.
- Treating metadata as a ranking guarantee: it improves how correctly a page is represented, not its position.
- Canonical URL pointing at the wrong page: verify it resolves to the intended page, not a redirect or 404.
Accessibility, security, and performance
A descriptive, accurate title benefits screen reader users navigating between browser tabs just as much as it benefits search snippets — this is one place where SEO and accessibility genuinely overlap rather than compete. Do not rely on meta tags to convey information that should be in visible, semantic body content; a screen reader does not announce your description or Open Graph tags while reading the page itself.
Never put private or sensitive information in metadata under the assumption that "it's just in the head" makes it hidden — head content ships to every visitor and crawler exactly like body content. noindex is a request, not a security boundary; a truly private page needs authentication, not a robots directive. Metadata tags themselves are lightweight and add negligible transfer weight; the real performance cost in this area comes from oversized og:image files, so apply the same compression discipline from lesson 005.
Tiered exercises
Level 1: write
Write a title and description for Rina's order.html page that a stranger could use to decide whether to click through, without having seen the page.
Level 2: apply
Add description, canonical URL, favicon, and Open Graph tags to Rina's index.html. Verify every value is consistent with the actual page content.
Level 3: audit
Check every page of your own portfolio and Rina's site for duplicated titles/descriptions, a missing favicon, or a relative og:image. Fix each and explain why the fix matters to a specific kind of reader (browser tab, search snippet, or chat link preview).
Level 1:
<title>Order a Custom Cake | Rina's Kitchen</title>
<meta name="description" content="Order a custom cake from Rina's Kitchen. Choose a size, add-ins, and a pickup date at least three days ahead.">
Level 2: the guided example above is a complete answer. The description mentions the opening-hours table and cake-order form actually present on the page; the canonical URL matches the real deployed address; the favicon link uses a root-relative path shared by every page.
Level 3: a correct audit finds each page has a distinct title/description matching its own main content, exactly one favicon declaration repeated identically across pages, and an absolute og:image URL that loads successfully when pasted into a browser tab directly. The explanation should distinguish: the tab reads title; a search engine may read description; a chat app reads the Open Graph tags — three different readers, each needing an accurate, non-duplicated answer.
Recap and exit questions
Head metadata is a promise to readers who never see your rendered page directly — browser tabs, search snippets, and link-preview cards. Write it after the content exists, keep it specific to each page, and remember that it can only accurately represent good HTML, never substitute for it.
- Why must
og:imageuse an absolute URL while an internal navigation link can stay relative? - What is the risk of copying one page's
titleanddescriptiononto another page? - What does
rel="canonical"solve thattitlealone cannot? - Why is
noindexnot a privacy or security control? - Name two SEO-relevant decisions you already made before this lesson, back in lessons 003–006.