SEO gets talked about as a bag of tricks — magic words to sprinkle on a page. It isn't. It's the practical consequence of three separate systems, each with its own real constraints: a page has to be crawled, then indexed, then ranked — and nearly everything this course covers maps onto making one of those three stages go well.

The Three-Stage Pipeline

These are genuinely separate hurdles. A page can fail at any one of them independently of the others — beautifully written, keyword-perfect content that nothing links to never gets past stage one, no matter how good stage three would have gone.

SEO vs. Paid Search

The results in a search page split into two genuinely different systems: organic results, produced by the crawl/index/rank pipeline above, and paid results (search engine marketing, SEM), produced by an entirely separate real-time auction where advertisers bid for placement. This course is about the organic side only — SEM is a real, substantial topic of its own, deliberately out of scope here rather than covered thinly.

An Honest Caveat, Stated Early

This Course's Own Roadmap

seo1-9 covers measuring whether any of this actually worked, and seo1-10's own capstone traces this exact pipeline for a real site.

Hands-On Exercises

html2-5's own "Meta Tags" chapter named SEO basics as one of its topics without ever teaching how to actually write a good title or description. This chapter delivers on that preview in full — the highest-leverage on-page work a page can have, and genuinely quick to get right once the reasoning behind it is clear.

The Title Tag — Doing Two Jobs at Once

<title>Hiragana Stroke Order Guide — Philip's Learning Blog</title>

The <title> is both a real ranking signal (seo1-1's own ranking stage reads it directly) and the clickable blue link shown in a results page. A title stuffed with repeated keywords can work against both jobs at once — it reads as manipulative to a ranking algorithm built to detect exactly that pattern, and it looks unappealing enough to a real person that it lowers the click-through rate even for a page that did rank well.

Meta Descriptions — Not a Ranking Signal, but a Real Lever

<meta name="description" content="A clear, illustrated guide to hiragana stroke order, with example words for each character.">

Headings — Structure a Crawler Can Actually Use

web-accessibility1-2 already covered heading hierarchy in depth for screen-reader users navigating by landmark. The exact same structure a screen reader relies on to understand a page's own outline is what a crawler uses to understand which content is the main subject versus a subsection — one clean <h1>, logically nested <h2>/<h3> underneath, no skipped levels.

Hands-On Exercises

seo1-1's own ranking stage draws on hundreds of signals — but the content itself, what a page actually says, is what most of them are ultimately trying to evaluate. This chapter covers writing content a search engine (and a real reader) has genuine reason to trust.

Search Intent — What Is the Searcher Actually Trying to Do?

A page that ranks for a query but doesn't match what the searcher was actually trying to do produces a bad outcome for everyone — the searcher bounces immediately, and that bounce is itself a real signal ranking systems can pick up on over time. Matching intent isn't a nice-to-have layered on top of good content; it's what "relevant" actually means.

Correcting an Outdated Myth

E-E-A-T — Experience, Expertise, Authoritativeness, Trustworthiness

A framework Google's own quality-rating guidelines use to describe what separates genuinely reliable content from content that merely looks reliable:

• Experience — has the author actually done the thing being described, not just researched it secondhand?
• Expertise — does the content demonstrate real, specific knowledge of the subject?
• Authoritativeness — is this source recognized, by others, as a legitimate voice on this topic?
• Trustworthiness — is the site and the content itself honest, accurate, and transparent?

Hands-On Exercises

html_lesson_09_2 already taught the markup mechanics of microdata and Schema.org. What it didn't cover is why a search engine cares — this chapter delivers that half in full: structured data as a direct line to a richer, more clickable search result.

What Structured Data Actually Does

A page's own visible text tells a human reader what it's about. Structured data tells a machine the exact same thing, unambiguously — this is a recipe, this field is the cook time, this field is the rating. Without it, a search engine has to infer meaning from plain prose; with it, the meaning is stated directly, in a format built specifically to be machine-read.

JSON-LD — The Practical Default

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Hiragana Stroke Order Guide",
  "author": { "@type": "Person", "name": "Philip Osztromok" },
  "datePublished": "2026-01-15"
}
</script>

html_lesson_09_2 covered inline microdata (itemscope/itemprop attributes woven directly into visible HTML). JSON-LD does the identical job — describing the same schema.org vocabulary — as one self-contained script block, entirely separate from the visible markup. This is now the format Google's own documentation recommends by default, specifically because it doesn't require touching the page's own display HTML at all.

The Actual Payoff — Rich Snippets

A Real Gotcha: Marked-Up Data Must Match Visible Content

Structured data claiming a 5-star rating on a page that shows no visible rating anywhere is a real, documented policy violation, not a clever trick — search engines actively check for this mismatch and can remove rich-result eligibility (or apply a manual penalty) for structured data that misrepresents what's actually on the page.

Hands-On Exercises

This is the course's own central technical chapter — where seo1-1's own crawling and indexing stages get their real, concrete tools.

robots.txt — The Other Side of dsproj1-1's Own Warn-Box

# /robots.txt
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Allow: /

Sitemap: https://example.com/sitemap.xml

robots.txt is a request, not a lock — well-behaved crawlers (including Googlebot) honor it, but nothing technically prevents a page from being fetched by something that ignores it. It manages crawl behavior for cooperative bots; it is not a security or access-control mechanism.

Sitemaps — Making Pages Findable Without Relying on Links Alone

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/japanese/hiragana</loc>
    <lastmod>2026-07-17</lastmod>
  </url>
</urlset>

Canonical Tags — Telling a Search Engine Which Version Is Real

<link rel="canonical" href="https://example.com/japanese/hiragana">

The same content is often reachable at more than one URL — with and without a trailing slash, with a tracking parameter, over HTTP versus HTTPS. Without a canonical tag, a search engine has to guess which version is the "real" one to index and rank, and duplicate versions can dilute ranking signals that should have been concentrated on a single URL. The canonical tag states the answer directly.

noindex — Removing a Page From the Index on Purpose

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

A genuinely common mistake: blocking a page in robots.txt and also adding a noindex tag. Since robots.txt already prevents the page from being crawled, the crawler never sees the noindex instruction at all — the two tools solve different problems and using them together on the same page is usually redundant at best, contradictory at worst.

Mobile-First Indexing

Search engines now primarily use a site's mobile version to crawl and index content, not the desktop version — meaning a page whose mobile layout hides or omits content the desktop version shows is effectively invisible for that missing content, indexing-wise. This is fundamentally a crawling/indexing concern, not a new design topic — the actual responsive-design techniques that solve it are css_beginner_11's own material in full; nothing here needs re-teaching, only applying with this specific consequence in mind.

Hands-On Exercises

web-vitals1 already taught LCP, INP, and CLS in full technical depth, framed entirely as a user-experience concern. This chapter doesn't re-teach the mechanics — it delivers the other half: these three metrics are also real, Google-confirmed ranking signals, not just a UX nicety with no bearing on visibility.

The Core Web Vitals, Reused Directly

Nothing about how these are measured or improved changes here — web-vitals1-2 through web-vitals1-4 remain the authoritative source for the technical work itself. What this chapter adds is the missing context for why that work matters beyond visitor satisfaction.

An Honest Note on Weight

Where Performance and Crawling Actually Intersect

Hands-On Exercises

Everything so far has treated a page mostly in isolation. This chapter zooms out to how pages relate to each other — a real, distinct layer of SEO that no earlier chapter has touched.

Clean URLs

A URL is itself a small, persistent piece of context — shown in search results, shared directly, referenced in links. It doesn't need keywords stuffed into it (seo1-3's own caution against stuffing applies here too), just a clean, stable, human-readable path.

Internal Linking & Link Equity

Every internal link is a small vote of relevance from one page to another — search engines use this internal linking pattern to judge which pages a site itself treats as important. A page linked from dozens of other pages across a site sends a different signal than a page linked from nowhere at all.

Breadcrumbs

A visible trail — Home > Japanese > Hiragana — that does double duty: it helps a visitor understand where they are and navigate up a level, and it gives a crawler an explicit, low-effort signal of the page's own place in the site's overall hierarchy. Breadcrumbs are also a common target for the structured-data markup seo1-4 already covered, unlocking a breadcrumb trail shown directly in the search result itself.

Site Architecture & Content Silos

A "silo" groups closely related content under a shared structural path — every hiragana-related page living under /japanese/hiragana/, every kanji-related page under /japanese/kanji/ — rather than scattering topically related pages across unrelated, disconnected paths. This isn't just tidiness: a search engine reading a site's own URL and linking structure can use consistent silos as a signal of genuine topical depth on a subject, one instance of seo1-3's own E-E-A-T material made structural rather than purely textual.

Hands-On Exercises

seo1-7 covered internal links — votes a site casts for itself. This chapter covers the external kind: links from other sites, and why they carry real weight precisely because they're harder to fake than anything on a page itself.

Why a Backlink Is a Genuinely Different Kind of Signal

Every earlier chapter covered signals a site controls directly — its own title tags, its own content, its own structure. A backlink is different: it's another, independent site choosing to link to this one. That independence is exactly what makes it valuable as a trust signal — it's much harder to fabricate at scale than anything living entirely within one site's own control.

Not All Links Carry Equal Weight

<a href="https://example.com" rel="sponsored">a paid placement</a>

rel="sponsored" and rel="nofollow" exist specifically so a site can link out honestly — to a paid partner, to user-submitted content it can't fully vouch for — without that link being read as an unqualified endorsement.

Real Link-Building Value

Genuine backlinks accumulate as a natural consequence of content worth referencing — original research, a uniquely useful resource, something no one else has built quite the same way. Earning links this way takes real time and real quality, which is exactly why it's a meaningful signal rather than a hollow one.

The Other Side: Real Manipulation Risk

Hands-On Exercises

Every technique in this course so far has been a change to make. This chapter is about finding out whether any of it actually worked — and being honest about how long that answer takes to arrive.

Google Search Console — The Primary Tool

Search Console is free, and it's the only tool giving a direct view into how Google itself sees a specific site — not a third-party estimate, the actual data.

The Coverage Report — Closing the Loop on seo1-5

seo1-5 covered robots.txt, sitemaps, canonical tags, and noindex as tools that shape what gets indexed. The Coverage report is where the actual, real-world result of those choices becomes visible — which pages Google has indexed, which it found but excluded, and, critically, the stated reason for each exclusion.

An Honest Framing, Stated Directly

Hands-On Exercises

Every prior chapter used illustrative examples. This one doesn't — it's a genuine audit of Philip's own live site (debserver\website\), based on a real source-level review conducted 2026-07-17. Every finding below is real; every fix is a genuine recommendation, not a hypothetical exercise.

Finding 1 — Crawling Is Effectively Broken for Most of the Site (seo1-5)

Fix: either build the missing tile-grid pages and link them from the main site nav, or add these ~300 URLs directly to a sitemap (seo1-5) as the explicit backup seo1-7's own exercise already named for exactly this scenario.

Finding 2 — No robots.txt, No Sitemap (seo1-5)

Neither file exists anywhere on the site. Per seo1-5, a sitemap is the direct fix for Finding 1; a robots.txt (even a minimal one excluding /admin/) is the site-owner-side counterpart to dsproj1-1's own scraper-side material.

Finding 3 — No Canonical Tags, No HTTPS-Enforcing Redirect (seo1-5)

config.php still hardcodes SITE_BASE_URL = 'http://localhost', and the one existing $canonicalBase variable in the anime sub-app is defined but never rendered into an actual <link rel="canonical"> tag anywhere in the codebase.

Finding 4 — No Meta Descriptions Anywhere on the Main Blog (seo1-2)

Neither template.php nor any of the static kanji/kana pages define <meta name="description">. The separate Anime Vault sub-app does have dynamic meta descriptions — direct, real evidence this is a gap in execution, not a gap in knowledge.

Finding 5 — <html lang="en"> Hardcoded Everywhere, Including on Japanese-Language Pages

Every page, including ones whose entire content is Japanese vocabulary, declares lang="en". For a multi-language learning site, this is a real, fixable mismatch between what a page says and what it claims to be.

Findings Summary Table

Chapter Attribution Table

Hands-On Exercises

Scope Note — What This Capstone Deliberately Doesn't Cover