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 accurately describe a page; add a favicon and canonical URL correctly; explain what HTML can and cannot do for search ranking; and audit both your portfolio and Rina's Kitchen site for metadata that gives visitors the wrong expectation.

Prerequisites and retrieval

Start with the finished semantic multi-page site from lessons 002–014. Before continuing, put into your own words why <title> serves two different audiences: it labels a browser tab and can also appear on a search results page. You first encountered that in lesson 002, and this lesson builds on it. Also recall from lesson 001 that an HTTP response contains headers as well as HTML bytes. Some metadata here overlaps with information a server header can provide, so keep track of which mechanism is responsible for which behavior.

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

The contents of head make claims to readers who do not start by reading the page body. That might be a browser tab, a search-results snippet, a chat application's link-preview card, or an automated crawler. These readers form an initial impression without rendering your CSS or waiting for your JavaScript. If a title says "Rina's Kitchen — Fresh Sourdough Daily" while the page is actually about hiring, the real failure is not that a search engine was fooled. It is that a visitor clicked with the wrong expectation and immediately lost trust. Search engines are also getting better at detecting that mismatch.

Think of each tag as a summary contract. Derive it from content that already exists, and update it when that content changes. Do not decide what the metadata should claim and then shape the page to fit the claim.

Most of the important SEO work was already present in earlier lessons, even though it was not labeled SEO. A logical heading hierarchy (003), meaningful link text instead of "click here" (004), context-appropriate alt text (005), and correct semantic landmarks (006) help crawlers as well as assistive technology. This lesson adds the smaller layer that specifically lives in head.

Description, canonical, and favicon

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Sourdough &amp; 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 honest sentences, roughly 120–160 characters, that someone might genuinely want to read before clicking. It is not a keyword inventory. Repeating phrases such as "bakery, bakery near me, best bakery" gives readers little useful information and conflicts with the guidance of most search engines. A search engine can still replace your description with a more relevant passage from the body for a particular query, so treat this value as a strong suggestion rather than a guaranteed snippet.

rel="canonical" becomes useful when the same page can be reached through multiple URLs, such as versions with and without a trailing slash or a URL carrying a tracking query string. Use an absolute URL and point it at the one address you want treated as the preferred version. Otherwise, ranking signals may be divided among several URLs that appear to be duplicate or near-duplicate pages.

A favicon is more than decoration. Browsers show it in tabs, bookmarks, and history, and omitting it can make an otherwise finished site feel incomplete. Use an SVG for crisp modern rendering and an .ico fallback when older support matters. Reference the icons from every page, not just index.html.

Indexing directives and language signals

A canonical URL expresses a preference among similar URLs; it does not prevent a page from being indexed. If a page must stay out of search results, use a separate indexing directive:

<meta name="robots" content="noindex, nofollow">

Use noindex intentionally for cases such as staging pages, private-but-publicly-reachable previews, or duplicate utility pages that should not appear in results. Do not add it casually to a production template. One copied directive can take an entire site out of search results.

robots.txt and <meta name="robots"> address different parts of the process. robots.txt can influence whether a crawler fetches a URL, while noindex is an indexing instruction discovered in the page or an HTTP header. If you block the crawler from fetching the page, it may never see the page-level noindex instruction.

The document language introduced in lesson 002 is metadata too:

<html lang="en">

Set it accurately on every page, and add lang to an individual passage when that passage switches languages. Correct language information helps search, translation, speech synthesis, and browser language tools choose appropriate behavior.

Guided example: give Rina's homepage real metadata

Return to the finished index.html for Rina's Kitchen that you built across lessons 002–013. Its head currently contains only charset, viewport, and title. Add metadata that describes what the page actually offers:

<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 the description while looking at the page's actual main content. Does it account for 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," remove that phrase: it is a subjective claim, not a useful summary, and gives a visitor nothing actionable. A practical test is whether a stranger could decide if the page is worth opening from this sentence alone, without seeing the page first.

Apply the same test to order.html. Its title and description should not be copies of Home's. A title such as "Order a Custom Cake | Rina's Kitchen" should lead to a description about sizes and pickup dates rather than opening hours. Copying Home's metadata onto every page is the common defect this lesson is designed to expose. It is the metadata equivalent of the copied aria-current mistake from lesson 012.

When a link to Rina's site is pasted into a chat application, the preview card will usually be assembled from Open Graph tags rather than from the 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. The platform creating the preview fetches that image independently, and it has no page URL against which to resolve a relative path. A relative value can therefore fail silently, leaving a blank or default image. Pick an image that still works when cropped square or wide because each platform controls its crop. The storefront photo from lesson 005 is a better choice than a screenshot filled with small, unreadable text.

Open Graph does not replace the page title or meta description; the values complement and repeat some of the same information. Keep them consistent instead of creating three unrelated summaries for one page.

Intermediate example: robots and structured data, used carefully

There are legitimate pages that should not be indexed, including a staging copy of Rina's site or an internal draft:

<meta name="robots" content="noindex, nofollow">

Use this only when that outcome is intentional. If noindex is accidentally placed on a real page, or remains after a staging page goes live, the page disappears from search results without an obvious browser error. The only way to catch that kind of defect is to inspect head directly, which is why lesson 014's baseline checklist should be extended with a metadata pass.

Structured data describes content in a shared vocabulary that a crawler can parse programmatically. It goes beyond ordinary meta tags and is commonly written as JSON-LD in a script element:

<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 from earlier lessons. If a search engine cannot parse the JSON-LD, it should still be able to find Rina's opening hours in the real table from lesson 007. Structured data is an additional signal layered over correct HTML, never a substitute for it.

Advanced optional extension: what metadata cannot do

No meta tag can make up for content that is absent, slow to load, or unusable by real people. A description promising "the most accessible bakery site" does not make keyboard navigation work if you skipped lesson 011's audit. A flawless Open Graph card does not repair the 404 behind its link. Ranking also depends on signals HTML cannot control, including links from other sites, load performance, and mobile usability. This course does not claim to cover all of those factors.

The tags in this lesson are best understood as the last five percent of a page that already has meaningful headings, honest link text, real alt text, and working forms. On a site that skipped those foundations, improved metadata mainly helps more visitors arrive at a broken experience sooner.

Common mistakes and debugging

Keyword-stuffed description: write one honest sentence a person would want to read, not a term list.
Identical title/description copied across pages: make each page's summary specific to its content.
og:image given a relative path: the preview platform fetches it independently, so use an absolute URL.
Forgotten favicon: reference one from every page, not only the homepage.
noindex left on a page after launch: inspect head directly; the browser provides no visible warning.
Structured data duplicating false information: make JSON-LD agree with the real, visible page content.
Treating metadata as a ranking guarantee: metadata improves how accurately a page is represented, not where it ranks.
Canonical URL pointing at the wrong page: verify that it resolves to the intended page rather than a redirect or a 404.

Accessibility, security, and performance

A clear, accurate title helps screen reader users distinguish among browser tabs just as it helps search snippets. This is a genuine overlap between SEO and accessibility. Do not use meta tags to communicate information that belongs in visible, semantic body content: a screen reader does not announce the description or Open Graph tags while reading the page.

Do not put private or sensitive information in metadata on the assumption that head is hidden. It is sent to every visitor and crawler just like body content. noindex is a request, not a security boundary; a truly private page needs authentication. The tags themselves add negligible transfer weight. In this area, the meaningful performance risk is usually an oversized og:image, so use the same compression discipline from lesson 005.

Tiered exercises

Level 1: write

Write a title and description for Rina's order.html page that lets a stranger 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. Check each value against the page's actual content.

Level 3: audit

Inspect every page of your portfolio and Rina's site for duplicated titles or descriptions, a missing favicon, or a relative og:image. Correct each problem and explain why the correction matters to a particular reader: a browser-tab user, a search-snippet reader, or someone viewing a 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. Its description refers to the opening-hours table and cake-order form that are actually on the page; its canonical URL is the real deployed address; and its favicon uses a root-relative path shared across pages.

Level 3: a correct audit finds a distinct title and description on each page, each matching that page's main content. It also finds exactly one favicon declaration repeated consistently across pages and an absolute og:image URL that loads when pasted directly into a browser tab. The explanation should keep the audiences separate: the tab reads title, a search engine may use description, and a chat application reads Open Graph tags. Each reader needs an accurate answer that is not just a duplicate of another page's metadata.

Recap and exit questions

Head metadata makes a promise to readers who may never inspect the rendered page directly: browser tabs, search snippets, and link-preview cards. Write it after the page content exists, tailor it to each page, and remember that metadata can represent good HTML accurately but cannot stand in for it.

Why must og:image use an absolute URL while an internal navigation link can stay relative?
What is the risk of copying one page's title and description onto another page?
What does rel="canonical" solve that title alone cannot?
Why is noindex not a privacy or security control?
Name two SEO-relevant decisions you already made before this lesson, back in lessons 003–006.