Answers to Selected Exercises

Worked solutions and model analyses for the starred (†) and odd-numbered exercises from each chapter. SEO skill is learned by working on real sites, not by reading conclusions — attempt every exercise, and especially every Rivertown Home Services entry, before reading its solution.

Exercise 1.1

Discover (Google learns the URL exists) → Crawl (Googlebot fetches the code) → Render (Google runs the JS to see the finished page) → Index (Google decides to store it) → Rank (at query time, Google orders the indexed candidates). The sixth thing, at query time, is Serve: Google assembles and displays the SERP.

Exercise 1.3

Googlebot is (c) an automated program. It sends a request to your server exactly as a browser would and downloads the page's code, at enormous scale, so Google can process the web. It is not a human reviewer and not a browser window anyone is watching.

Exercise 1.4 †

Crawl budget is shaped by (1) how much crawling your server can handle without slowing down — Google backs off if it detects strain — and (2) how much Google wants to crawl your site, a function of the site's importance and how often it changes. It is a non-issue for most sites because Google can easily crawl every page of a few-hundred- or few-thousand-page site many times over. It becomes a genuine constraint only for very large sites — large e-commerce catalogs, news archives, sites with hundreds of thousands to millions of URLs.

Exercise 1.5

It means the results page is a crowded, competitive surface, not a simple list of ten organic links. Besides standard organic listings, a SERP can show: paid ads (labeled "Sponsored"), an AI Overview, a featured snippet (position zero), a People Also Ask box, a local pack (map + businesses), image and video carousels, a knowledge panel, shopping results, and sitelinks.

Exercise 1.7

The alignment argument: Google's business depends on searchers being satisfied with results, so Google wants to surface the genuinely best page; a publisher wants their genuinely useful page to reach its audience — the same outcome, so cooperating with Google beats fighting it. The honest caveat: "best" is Google's fallible, business-shaped judgment (ads sit above and around organic results, and its algorithms are often wrong), so alignment is a sound strategy, not a guarantee that Google will always reward the best page.

Exercise 1.9 †

For a non-technical owner: think of your page as arriving in two forms. The "raw" form is what the server sends first; the "finished" form is what appears after the page's own programs (JavaScript) run in the visitor's browser. A human's browser always runs those programs, so they see the finished page. A search engine has to do that work separately and at massive scale, so it sometimes runs the programs late, or imperfectly, or (rarely) not at all. If your content and links exist only in the finished form, you're betting your visibility on that extra step always working for you. If they're already in the raw form the server sends, there's nothing to wait for and nothing to fail — the search engine sees your content immediately.

Exercise 1.11

Once you believe indexing is a quality gate, you stop assuming publication equals participation. Your priorities shift from "produce more pages" toward "make sure the pages I have are good and unique enough to be kept, and confirm they actually are indexed." You check index status before diagnosing rankings, and you treat thin/duplicate content as an active liability rather than harmless filler.

Exercise 1.13

There is no single universal ranking because results are shaped by who is searching and from where. Two named signals from the chapter: location (someone in Northgate and someone in Westbrook see different local results for "plumber") and device (mobile vs. desktop can differ); language and some search history also personalize results. So "we rank #3" is incomplete without "for whom, and where?"

Exercise 1.15 †

The failing stage is discovery: nothing links to the page and it's not in the sitemap, so Google has no road to it — it is an orphan. The fix category is discovery/crawlability, not content: add internal links from relevant existing pages and include the URL in the XML sitemap (Chapters 14–15). Only after Google can find the page does asking about its content or rankings make sense.

Exercise 1.16 †

"Crawled — currently not indexed" is an indexing-stage problem: Google fetched the page and chose not to store it, usually a signal that it judged the page thin, duplicative, or low-value. Building links is a ranking-stage move, and you cannot rank a page that isn't in the index — so links are the wrong first step. The right move is to address why Google declined to index it: improve the page's uniqueness and value (or merge/remove it), then request indexing.

Exercise 1.17

The failing stage is rendering. The URL Inspection tool shows Google's rendered HTML with the product areas empty, meaning the content that only appears after client-side JavaScript wasn't present when Google rendered the page — so there is effectively nothing for indexing or ranking to work with. The fix lives in Chapter 19 (server-side rendering, static generation, or ensuring content is in the HTML).

Exercise 1.19

The two stages in tension are discovery/crawling and indexing: Google has discovered 40,000 new URLs but hasn't prioritized crawling and indexing them ("Discovered — currently not indexed"). The concept from §1.2 that explains the delay is crawl budget / crawl scheduling: at large scale, Google crawls on its own schedule and priority, and a sudden flood of low-priority, likely-thin URLs sits in the queue — a case where scale genuinely matters (and where dumping 40,000 filter URLs was probably a mistake; see Chapter 31).

Exercise 1.21 †

(Guided — answers vary by site.) The deliverable is a single interpretive sentence tagging the site: count as a symptom. Example: "site: reports ~1,200 pages when I expected ~300 — likely index bloat from filter/parameter URLs, an indexing-stage symptom to investigate in Ch 14." A much lower number than expected points instead to a discovery or indexing failure (are the real pages linked and indexable?). The point is to name the stage, not to fix it yet.

Exercise 1.23

(Guided.) If the homepage's headline and body text are visible in "View Page Source," rendering risk is low — the content is in the raw HTML. If the source is nearly empty with a pile of scripts and a root <div>, the content depends on JavaScript rendering, and rendering risk is real (investigate with URL Inspection; see Ch 19). One-sentence answers will vary by platform; WordPress and most traditional CMSs pass, many single-page apps do not.

Exercise 1.25 †

The most alarming line is "Excluded by 'noindex' tag": 74 — a third of the site is actively telling Google not to index it, which for a small business is very often an accident (a leftover staging block, a misconfigured plugin), and it removes those pages from search entirely. It implicates the indexing stage. Before touching any content, check why those 74 pages carry noindex: inspect a sample in Search Console, confirm whether the tag is intended, and look for a site-wide or template-level cause. (The duplicate-canonical and crawled-not-indexed lines are lower-priority quality issues by comparison.)

Exercise 1.27

Two bundled myths. (1) "Exactly 200 ranking factors" — the number is folklore from an old Google comment; the real count is unknown, changes constantly, and isn't a meaningful target. Truth: Google uses many signals and machine-learned systems, and confirms only a fraction. (2) "SEO is checking off all of them" — ranking is not a checklist you complete; it is a relative contest. Truth: you don't need to be "fully optimized," you need to be a better answer than the competing pages, in Google's estimation.

Exercise 1.29 †

(a) Three new service pages took six weeks to appear → discovery (they are orphans / not in the sitemap, so Google was slow to find them; fix with internal links + sitemap, Ch 14–15). (b) The water-heater guide is indexed but stuck at #11 → ranking (it's technically healthy but loses the contest on intent match, comprehensiveness, and internal-link authority; Ch 3, 9, 15). (c) Old blog posts get zero traffic and several aren't indexed → indexing/ranking driven by thin content (audit and prune/improve; Ch 12).

Chapter 2 — Worked Solutions (daggered † and odd-numbered exercises)

Exercise 1

A ranking signal is a measurable input the ranking machinery may look at — e.g., the links pointing to a page. A ranking system is a software component that uses signals to do a job — e.g., RankBrain, interpreting query meaning. A ranking factor is the loose industry word for "a signal, treated as something to act on" — e.g., "backlinks are a factor." How they relate: signals feed systems, and systems produce the ordering; "factor" is a convenience word that becomes dangerous when it implies a checklist of independent levers instead of a contest.

Exercise 3

Any five of: relevance / intent match (big — the top lever); links (medium-to-strong, but not raw 1998 PageRank); mobile-first indexing (medium — a floor to clear); HTTPS (light — Google called it lightweight, under 1% of queries); Core Web Vitals / page experience (light — a tiebreaker); language / locale (query-dependent, decisive for local/multilingual); freshness for some queries (query-dependent). The defense point: your "weight" words are estimates informed by Google's own characterizations, and the whole exercise proves that "confirmed" told you nothing about ordering — you had to reason about weight separately.

Exercise 5

RankBrain (2015) — Google's first major machine-learning ranking system; helps interpret query meaning, especially novel queries. BERT (2019) — a natural-language model that reads words in context, moving ranking from string-matching toward meaning. MUM (2021) — a more powerful, multimodal model; real and announced, but with a vague/narrow confirmed role in live ranking.

Exercise 7

"Confirmed" establishes only that a signal exists and is used; it says nothing about magnitude. HTTPS is the model case: Google confirmed it as a signal and, in the same announcement, called it lightweight and said it touched well under 1% of queries. So a site that switches to HTTPS has done a correct, confirmed thing and should expect essentially no ranking movement from it alone — because if the page is losing on relevance, a lightweight signal cannot rescue it. Existence and weight are two separate claims; conflating them is how people waste months on confirmed-but-trivial work.

Exercise 8

Reverse causation means the causal arrow runs opposite to the assumed direction. The study assumes links → ranking. But a page that already ranks #1 is seen by far more people, so it earns more links precisely because it ranks well: ranking → links. Both directions are plausible and probably both operate, so the raw correlation ("#1 pages have more links") cannot tell you how much of the gap is links lifting rankings versus rankings attracting links. The study is consistent with links mattering, but it does not prove that building links will move your page — the arrow may be pointing back at you.

Exercise 9

Because large parts of modern ranking are machine-learned: systems trained on huge datasets store their "knowledge" as millions of tuned numerical weights, none of which corresponds to a human-readable rule. Add that ranking is a system of systems (RankBrain, BERT, helpful-content, spam, PageRank's descendants, and more, interacting), and the behavior is emergent — it arises from the combination, not from any single readable component. Google's engineers can describe how the systems are built and what they're trained to do, but "page A beat page B because of X, Y, Z weighted thus" is a sentence that doesn't exist inside the machine.

Exercise 10

The claim is unfalsifiable — no possible observation could prove it wrong, because any page that fails to rank is retroactively redefined as "not really quality." A statement that can absorb every outcome makes no risky prediction and therefore carries no information; it's a belief, not knowledge. (Contrast a testable claim: "adding an accurate, descriptive title will raise this page's click-through rate," which a before/after check could refute.) The flaw's name: unfalsifiability / circular reasoning.

Exercise 11

A no-regret move pays off on both sides of an uncertain bet: if the signal is real you win a ranking benefit, and if it isn't you still win because you've improved the site for its human users. Covering a topic thoroughly and earning genuine engagement qualify — they serve the reader regardless of whether Google counts them. Bot-driven CTR manipulation is the opposite: it does nothing for the reader, almost certainly doesn't work (Google denoises and defends against it), and carries risk — so if you're wrong you've simply wasted effort and possibly harmed trust. Prefer moves that are good even if the "factor" turns out to be a myth.

Exercise 13

Keyword stuffing is real and risky: cramming a term unnaturally is a spam signal Google can act against. Keyword density — the belief in an ideal percentage of keyword use to hit — is a myth: there is no such target, and Google has said so repeatedly. Modern language understanding (BERT and successors, §2.5) reads the meaning of the page, not a term-frequency ratio, so "tune your density to 2%" optimizes a quantity the systems don't evaluate in that form. Write naturally; the only nearby reality is the downside (stuffing), not an upside dial.

Exercise 14

Word count: the confounder is thoroughness. Comprehensive answers tend to be longer and tend to rank (because they satisfy intent), so length and ranking move together without length causing ranking. Wasted action: padding pages to a word target, which adds fluff and makes them worse. Domain age: the confounder is accumulated authority (links + content built over time). Older domains have had more years to earn those, so age and ranking correlate without age causing ranking. Wasted action: buying "aged" domains or assuming an old domain is set. In both, a third variable drives both observed things.

Exercise 15

The most likely real problem is an intent / relevance mismatch (or simply that competitors are a better, more complete answer) — a ranking-stage problem. Notice that every attribute listed (indexed, fast, HTTPS, mobile, long, "2% density") is either a confirmed-but-lightweight signal or an outright myth; none of them is relevance, which is the biggest lever. The page has optimized everything except the thing that matters most. The fix is not more of the same knobs; it's matching what the searcher actually wants and out-answering the pages above it (Chapters 3 and 9). Diagnose the stage: discovery/crawl/render/index are all passing; the break is at rank.

Exercise 17

Model report: the <meta name="keywords"> tag, if present, is a debunked "factor" — Google has ignored it since 2009, and it needlessly shows competitors your targets; recommend deleting it. A <meta name="viewport"> tag present indicates the page declares itself mobile-ready, which supports mobile-friendliness (a confirmed, medium-weight signal). An https:// address confirms HTTPS (a confirmed but lightweight signal). Interpretation: one thing to remove (does nothing / small leak) and two confirmed items to keep — and none of the three is where your ranking energy should go once they're handled. The point of the exercise is the habit of looking at what's actually in the page rather than trusting a checklist.

Exercise 19

Rubric (open-ended). A strong answer: places genuinely confirmed items (relevance, links, HTTPS, mobile, CWV, locale) in confirmed; places engagement, topical authority, and "comprehensiveness" in likely; places meta keywords, keyword density, word-count targets, domain age, "post daily" in debunked; and honestly flags several claims it cannot confidently place (that difficulty is the lesson). Bonus for noticing that the article formats confirmed and invented claims identically, and for spotting any correlation sold as causation.

Exercise 21

Sort first: "keyword in the title is a confirmed ranking factor" is an over-statement. What's confirmed is that Google uses the title to understand what a page is about and that the title is the highest-leverage on-page element for the click — but there's no guaranteed ranking boost from placing an exact keyword, and "must put it first" is folklore (rung 2 at best, dressed as rung 1). Rewrite for furnace repair Northgate, e.g.: "Furnace Repair in Northgate — Same-Day Service | Rivertown Home Services." Evidence supporting the rewrite: it communicates the topic clearly to readers and machines (confirmed use of the title), and it earns the click by matching intent (Chapter 9). What it does not do: guarantee a ranking — that depends on the competitors in Northgate, whom we don't control.

Exercise 23

Shows: a real correlation — higher-ranked pages tend to have more referring domains — consistent with links mattering (which, on other evidence, they do). Doesn't: show that links caused the rankings; reverse causation is wide open (ranking earns links), confounders abound (better sites have both more links and better content), the sample/query mix is unstated, and the publisher sells a link tool. Move: treat it as rung-2 support for a thesis you already hold on better grounds — not as proof of a weight or a mandate to go buy links. Lesson: a correlation study is a hypothesis generator, never a verdict; read the caveats the headline dropped, and ask which way the arrow points.

Exercise 25

Myth. Publishing frequency ("velocity") is not a ranking factor; Google has not said daily posting helps, and mechanically pumping out posts to hit a cadence tends to produce thin content that hurts a site's overall quality signal. What's true nearby: some sites publish often because their topic genuinely warrants fresh coverage (news), and freshness is query-dependent — but that's "update when the world changes," not "post daily to please Google." The durable move is quality and intent-match at whatever cadence the topic deserves (Chapter 8).

Exercise 27

At least four distinct errors: (1) "proves" — a correlation study cannot prove a causal claim. (2) the oddly precise "1,890" — false precision manufactured from average lengths; not a target Google uses. (3) "ideal length" as a factor — word count is not a ranking factor; length is a side effect of covering a topic well, not a cause of ranking. (4) ignores the confounder — thoroughness drives both length and ranking. (5, bonus) ignores query-dependence — the right length is set by the query and intent, not a universal number. Any writer who "hits 1,890 words" by padding makes the page worse.

Exercise 28

Does it work? Almost certainly not. Google's very reason for being cautious with click data is that raw clicks are noisy and gameable, so its systems denoise and defend against exactly this; bot or incentivized clicks are the manipulation those defenses target. Even given that engagement likely feeds ranking somewhere (the DOJ/NavBoost evidence), it does so through aggregated, defended systems — not a dial you can spin with fake traffic. Is it wise? No — it's spend on a tactic with no credible mechanism, it risks association with manipulation, and it diverts money from the no-regret work (a better title and a page that satisfies real users) that produces the genuine engagement you actually want. Decline it on both axes.

Exercise 29

Evidence: it will not help — Google has ignored the meta keywords tag since 2009 — so on effectiveness the answer is a flat zero. Ethics/risk: stuffing competitors' brand names into your markup to piggyback on their brand is deceptive and can create trademark/legal exposure, and it hands competitors a look at your intentions for nothing in return. Two sentences back: "The meta keywords tag has done nothing for ranking since Google confirmed it ignores it in 2009, so this won't move us at all. Putting competitors' brand names in our code adds legal and reputational risk for zero upside — I'd recommend we skip it and put the time into the pages people actually search for."

Exercise 30

Model sentences (any three items; honest, no promises): HTTPS — "Worth doing for security and it's a confirmed signal, but it's lightweight, so expect basically no ranking movement from it alone." Fix mobile speed / Core Web Vitals — "This matters most for the panicked customer on a phone; as a ranking signal it's a tiebreaker, so it helps at the margin, not as a magic lift." Make the city pages genuinely match what people search — "This is the big one — relevance is the strongest lever we have — but how far it moves us depends on the competitors in each city, so I can promise a better, more deserving page, not a specific position." The common thread: state the direction and honest magnitude, and never convert "confirmed lever" into "guaranteed result."

Exercise 31

True part: Google's quality systems are designed to reward signals that align with E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness), so it's fair to say E-E-A-T describes what Google is trying to reward. Misleading part: there is no single "E-E-A-T score" inside the algorithm and no direct "E-E-A-T factor" you can set — treating it as a knob is the error. The full answer, including how sites actually demonstrate E-E-A-T, lives in Chapter 5 (with YMYL depth in Chapter 35).

Exercise 32

Rubric (open-ended). A good answer states the invented "fix," assigns a tier, and justifies with this chapter's tools. Example: "A friend told Dave to add an FAQ section to every page 'because FAQs are a ranking factor.'" → Likely / partly folklore: FAQ content can help by matching real questions (relevance) and FAQ schema can earn a rich result (eligibility, not a ranking boost — Chapter 18), but "FAQs are a ranking factor" per se is unconfirmed; the value is in genuinely answering searcher questions, not in the format. Grade for correct tiering and for naming the confounder or the confirmed-vs-eligibility distinction.

Chapter 3 — Worked Solutions

Worked solutions to the daggered (†) and odd-numbered exercises.

Exercise 3.1

Search intent is the underlying goal a searcher is trying to accomplish with a search — the why beneath the what. A query is the literal text typed into the box (the what); the intent is the goal that text only points to. They come apart constantly: the same query ("apple," "mercury," "python") can carry different intents, so the words don't fully determine the goal. The practical upshot: you optimize to satisfy the intent, treating the keyword as a clue to it, not as the target itself.

Exercise 3.3

"The SERP is the answer key" means the results Google already ranks for a query reveal what Google believes searchers of that query want: the dominant format of the top results and the SERP features present are Google's aggregated verdict on the intent. It's the first move because it is free, fast, and lets the party with the most searcher data (Google) tell you what kind of page wins — before you spend effort on keyword research or writing the wrong kind of page. Reading it first prevents the single most expensive mistake: building a well-executed page of the wrong type.

Exercise 3.5

(a) "weather tomorrow" — informational (Know); wants a fact. (b) "nike" — navigational; wants Nike's own site. (c) "best running shoes for flat feet" — commercial investigation; comparing before buying. (d) "buy nike pegasus size 10" — transactional; ready to purchase a specific product. (e) "how to clean running shoes" — informational; wants a method. Note that (c), (d), and (e) all contain "shoes" yet demand three completely different page types — the point of the exercise.

Exercise 3.7

A 50/50 split is a signal, not noise: Google sees more than one legitimate intent for the query and is hedging between them. It changes your decision in two ways. First, you get to choose which intent to serve — usually the one you can serve best and that is most valuable to you. Second, it warns you that whatever you build will share page one with a different species of result, so you shouldn't expect to sweep the SERP. If the two intents are genuinely distinct, it may also be a hint to serve them with two pages rather than one straddling page (a content-strategy call developed in Chapters 8 and 12).

Exercise 3.9

This is textbook intent mismatch. Per its SERP, "espresso machine" has a dominant commercial investigation intent — searchers want to compare before buying — but the page is a single-product transactional page. No amount of extra keywords fixes a wrong-page-type problem. The fix is to match the intent: build (or add) a genuine comparison / buying guide — criteria, honest pros and cons across several machines, a recommendation, and answers to the SERP's "People also ask" questions — and route the now-decided buyer to product pages from there. Match the intent first; convert second.

Exercise 3.11

Two intent-related explanations for a slow, edit-free drift from #3 to #12: (1) market maturity / intent drift — the query's dominant intent has shifted (e.g., from informational to commercial as the category matured), so the SERP now rewards a page type the page doesn't provide; (2) SERP-feature / competitive change — new features (an AI Overview, more product results) or newer, better-intent-matched competitors reshaped the page and pushed it down. First check: re-read the current SERP and compare it to what the page offers — has the dominant intent or format changed since the page last ranked well? A fade is often the sound of intent shifting underneath a page.

Exercise 3.13

Impressions-but-few-clicks means the page does surface for a query but searchers skip it. Two readings: a weak, unappealing title/meta (Chapter 9), or an intent mismatch — the page appears for a query whose searchers want a different page type. To tell them apart, search the query and read the dominant intent: if the SERP is all guides and your page is a product page (or vice versa), mismatch is likely and reshaping the page beats rewriting the title; if the page type matches but the listing is dull, it's a title/meta job. Diagnose which before you act.

Exercise 3.15

For "drain cleaning": Informational — "why is my drain draining slowly" → a how-to/explainer wins. Commercial investigation — "hydro jetting vs snaking" (or "drain cleaning cost") → a comparison / cost guide wins. Transactional / local — "24 hour drain cleaning near me" or "drain cleaning Northgate" → a fast local service page plus the local pack wins; content alone won't (this is a local-pack fight). One service, three intents, three different responses.

Exercise 3.16

A ranking is never promised; the goal is to match intent. A better, intent-matched title might be: "Water Heater Replacement: Cost, Signs You Need One, and DIY vs. Pro (2026)." Top three H2 sections, serving the dominant informational/commercial intent (and its top micro-intents): 1. "How much does it cost to replace a water heater?" (cost is usually the #1 micro-intent), 2. "Signs it's time to replace — not repair — your water heater," 3. "Can you replace it yourself, or should you hire a pro?" …followed by a low-pressure "Or let Rivertown's licensed technicians handle it" section for the transactional micro-intent. The page now leads with what most searchers want and offers service second. (Exact tag mechanics — length, pixel truncation, meta description — are Chapter 9.)

Exercise 3.17

Rebuild the single-product pitch into a comparison / buying guide that matches commercial-investigation intent: open with the decision the searcher faces (MERV rating, size, use case), compare several real options honestly with pros/cons and a criteria-based recommendation, answer the SERP's PAA questions (how to find your size, how often to change it), and only then present your product as one recommended option. The call-to-action should be medium strength — "check your filter size," "see recommended filters" — matching a searcher who is deciding, not a hard "buy now" aimed at someone already ready.

Exercise 3.18

• THE QUERY / PAGE: "how to relight a furnace pilot light."
• WHAT'S THERE: a featured snippet with numbered steps; eight how-to articles; a video thumbnail; a "People also ask" box; zero service pages in the top ten.
• WHAT IT SHOWS: unambiguously informational — searchers want to do the task now. The steps snippet tells you Google thinks a concise numbered procedure is the ideal answer shape.
• WHAT IT DOESN'T: it doesn't reveal how many searchers will give up and hire a pro, or how commercially valuable they are — informational queries can still feed a business indirectly.
• THE MOVE: publish a clear, correct, genuinely helpful how-to (consider a short video), with a low-pressure "if the DIY route fails, here's how we can help" offer — not a sales page.
• THE LESSON: when the SERP is wall-to-wall how-tos, the winning move is to teach, not to sell.

Exercise 3.19

The shopping carousel and product-category pages mean the intent is transactional / commercial shopping — Google is serving buyers and near-buyers — and the "how much is…" PAA shows price is a live micro-intent. Build a strong product or category page (clear pricing, availability, trust signals, easy filtering), not a blog post. If you also want the researcher slice, a buying guide can capture the commercial-investigation micro-intent, but the dominant response the SERP rewards is a transactional page.

Exercise 3.21

False, because matching intent is necessary but not sufficient. Many competing pages also match the intent; among intent-matched pages, ranking is decided by authority, comprehensiveness, speed, and overall site strength. The honest version: "Matching intent is the price of entry — it gets you into the right contest; you still have to be the best answer among the pages that also match it."

Exercise 3.22

This is deceptive intent-bait: it targets an informational intent it doesn't actually satisfy. It fails on three fronts. (1) User trust: searchers who wanted to learn get a sales pitch, bounce, and don't come back — poor engagement signals and reputational cost. (2) Durability: Google's language understanding (see BERT, Case Study 3.1) and quality systems increasingly detect content that doesn't satisfy the query, so such pages tend not to rank durably and are exposed to updates. (3) Alignment: it's the adversarial framing the whole book rejects. The honest alternative that still serves the business: genuinely satisfy the informational intent (a real, helpful how-to), earn trust, and offer the product as a low-pressure option to the reader who — now helped — is ready for it. That serves user and business, and it lasts.

Exercise 3.23

Trust the "94% confidence" label as a starting guess, not ground truth. Automated intent labels are inferred and can be wrong (especially on ambiguous, mixed, or local queries), and the confidence number is the tool's internal estimate, not a Google fact. Verify for free by reading the SERP yourself: run the query (incognito, from the location that matters) and check whether the page types that actually rank match "transactional" (product/service pages, a local pack, shopping) or contradict it (guides, explainers). The live SERP overrules the label.

Exercise 3.24

• "emergency electrician" — transactional / local (Do / Visit-in-person): someone needs help now. This is a local-pack fight (Google Business Profile, reviews, proximity, click-to-call) plus a fast, trustworthy emergency service page. Content alone won't win it.
• "how to reset a tripped breaker" — informational (Know): a clear how-to (and possibly a short, safety-conscious video) wins; a sales page would mismatch. Because this is electrical (YMYL-adjacent), teach responsibly and advise calling a professional where real risk exists — a framing developed in Chapter 35.

Exercise 3.25

"furnace repair Cedar Hills" is transactional / local — the searcher wants a nearby pro to fix a furnace now. Rivertown's thin, near-duplicate location page contains the right words but doesn't satisfy that intent: it demonstrates no genuine local presence, trust, or ability to serve that specific city, and it competes poorly against the local pack. Winning requires two battlegrounds: (1) the local pack — Google Business Profile, reviews, NAP consistency, proximity (Chapter 25); and (2) a genuinely local, non-duplicate service×city page with real local content and internal support (Chapters 15 and 33). The right words on a thin page lose to the right intent served well.

Exercise 3.27

"Read the SERP once and trust it forever" is bad advice because intent and SERPs change, so a plan validated by last year's SERP can be quietly invalidated. Two reasons intent shifts: (1) market maturity — as a category moves from "learning" to "buying," its queries drift from informational to commercial/transactional and the SERP fills with comparison and product pages; (2) SERP features / AI Overviews — an AI Overview atop an informational SERP can capture the value of the intent, so ranking pages lose clicks even while still matching. (Also acceptable: seasonality/events; Google's improved comprehension re-interpreting the query.) Example: a "what is a heat pump water heater" explainer that dominated the learning phase loses ground as buying guides take over the maturing SERP.

Exercise 3.29

A transactional / local query such as "ac repair near me" (or "emergency electrician"). Building a blog post is the wrong move because the SERP is a local pack plus ads plus local service pages — a how-to can't compete and isn't what the searcher wants. Invest instead in local SEO: Google Business Profile optimization, reviews, NAP consistency, proximity signals, and a fast, trustworthy local service page (Chapter 25). Some queries are won in the pack, not with content — reading the SERP tells you which.

Chapter 4 — Worked Solutions (daggered † and odd-numbered exercises)

Exercise 4.1

A string is a sequence of characters — a word or phrase as typed. A thing (entity) is the real-world object or concept a string refers to, independent of any particular word. One string → many entities: "jaguar" (an animal, a car brand, an NFL team, a guitar). Many strings → one entity: "furnace," "heating unit," "forced-air heater," and Spanish "caldera" can all point to the same home-heating appliance. SEO now targets the thing and the need, not the string.

Exercise 4.3 †

An entity is a single, well-defined, distinguishable thing or concept (person, place, organization, product, event, idea). The Knowledge Graph is Google's database of entities and the relationships between them (nodes and edges). The knowledge panel is the on-SERP box of facts Google shows for a recognized entity. Relationship: the entity is the item (a node), the Knowledge Graph is the database that stores it and its relationships, and the knowledge panel is the visible readout of what the graph knows about that entity.

Exercise 4.5

Inverse document frequency (IDF) rewards distinctiveness: a term that appears in few documents across the whole collection is informative and scores high, while a term in nearly every document is uninformative and scores near zero. "The" appears in essentially every document, so N / n(t) is about 1 and its log is about 0 — no weight, no matter how often a page repeats it. A rare term like "anode rod" appears in few documents, so its IDF is solidly positive. IDF is the math of "distinctive words describe your content; common words don't."

Exercise 4.7 †

Google no longer requires the literal string. It resolves the query "annual heating tune-up" to its entity (the maintenance service for a heating system) and intent (schedule/learn about periodic furnace maintenance), then matches pages that are genuinely about that thing and need. A "furnace maintenance" page that covers seasonal servicing, what a technician checks, frequency, and cost co-occurs with the concepts real maintenance content contains, so Google reads it as about the same topic — and can rank it for the never-used phrase. Meaning matching, plus co-occurrence and topical coverage, closes the gap between the words on the page and the words in the query.

Exercise 4.9

Synonyms and related concepts help because (a) context (§4.3): surrounding language tells Google which entity you mean and how thoroughly you cover it; (b) co-occurrence (§4.3): the related concepts a genuine expert uses signal real depth; and (c) semantic search understands "fix my furnace," "furnace not working," and "heating repair" as one need, so you don't dilute a keyword by varying it — you demonstrate coverage. The old fear of "diluting the keyword" belongs to the string-matching era; a meaning engine rewards natural, complete language.

Exercise 4.11 †

Example (subject: home heating). Breadth = covering the whole topic: furnaces, boilers, heat pumps, thermostats, ductwork, and every common heating problem. Depth = covering each of those thoroughly — the furnace-ignition page genuinely explaining causes, diagnostics, fixes, safety, and when to call a pro. Breadth without depth backfires because you end up with many thin pages, and thin pages lower a site's overall quality signal (Chapter 12) instead of building authority — coverage only counts when each piece is genuinely substantial. You need both: breadth earns topical recognition; depth earns each ranking.

Exercise 4.13

A small business can hold stronger topical authority because topical authority is subject-specific recognition earned by genuinely covering a subject, not a measure of total site strength. A neighborhood HVAC company that has thoroughly covered furnace-ignition problems has demonstrated real depth on that narrow subject; a giant general-interest site with far more backlinks may never have covered it well. (Backlink-based third-party "Domain Authority" is a different, non-Google, non-topic-specific metric — Chapter 22.) Authority in a topic comes from covering the topic, which a focused small site can do better than a sprawling large one.

Exercise 4.14 †

(a) Entity: "the big tower with the lights in Paris" resolves to the Eiffel Tower — a specific place in the Knowledge Graph — even though its name never appears. (b) Intent: "a good place to grab a bite" expresses an informational/local need — find well-regarded restaurants nearby. A pure string-matching engine would look for pages containing "big tower," "lights," "grab a bite," and "Paris," miss that the phrase means the Eiffel Tower, and fail to connect "grab a bite" to restaurants — returning literal-word matches instead of the answer the searcher plainly wanted. Understanding the entity and the intent is what makes the query answerable.

Exercise 4.15 †

Diagnosis: the page targets a string ("water heater replacement") but is not genuinely about the topic. It lacks the concepts that co-occur with real water-heater content — anode rods, sediment buildup, the temperature-and-pressure relief valve, tank vs. tankless, sizing, typical cost, signs you need replacement, DIY-vs-pro. To Google's semantic systems it reads as thin and repetitive, not expert, so it earns little topical relevance despite its length. What to add (no new instances of the phrase): sections on how to tell a heater is failing; tank vs. tankless trade-offs; what a replacement involves and how long it takes; cost ranges and what drives them; the relief valve and anode rod; permits and safety; maintenance to extend life. That coverage supplies the co-occurring concepts that signal genuine depth — which is what actually moves relevance.

Exercise 4.17

"SEO the panel" is the wrong framing because a knowledge panel is not a page you rank or a field you edit — it is Google's readout of facts it assembled from many corroborating sources, so you fix the facts at the sources, not "in the panel." Honest path: (1) if you are the represented entity, verify/claim the panel through Google's process and suggest corrections; (2) correct the underlying data wherever Google draws it — your own site (with consistent, structured information), Wikidata, official profiles, and (for a local business) your Google Business Profile; (3) ensure consistency across all of them so Google's corroboration resolves to the right facts. Panels lag and are assembled, not authored — you influence, you don't control.

Exercise 4.18 †

Model response (process + what good looks like). Search your exact brand name and record: (a) whether a knowledge panel appears (many small businesses get only a local/GBP-driven panel or none — that is normal); (b) the "People also search for" brands, which reveal the entities Google associates with you (ideally real competitors/peers, not unrelated same-named entities); (c) whether a same-named entity intrudes (a disambiguation problem for §4.7). Good two-sentence read: e.g., "Google shows a modest local panel with the correct address and category and lists genuine competitors under 'People also search for,' so it understands us as a local HVAC entity — but a same-named business two states away sometimes appears, so our disambiguation signals (consistent context + sameAs) need work."

Exercise 4.19

Model response. Pick a page (say, a furnace-repair page). List the concepts an expert would expect: common failure symptoms, diagnostics, the ignition system/pilot, the heat exchanger, thermostat issues, safety/gas smell, repair vs. replace, cost drivers, maintenance. Then check how many the page actually covers. A typical finding: the page covers "we fix furnaces" and a phone number but omits most diagnostic and safety concepts — a large co-occurrence gap. The gap list is your content brief: adding those concepts (genuinely, not as a word list) is how the page signals real topical depth.

Exercise 4.21 †

Model response. Open Search Console → Performance → filter to one strong page → Queries. You will typically find the page ranks for many more distinct queries than the one you wrote it for — the head term plus dozens of long-tail variants and related phrasings you never explicitly targeted. That spread is direct evidence of topical coverage paying off: Google understands the page as covering a topic, not a single string, so one deep page harvests a cluster of related searches (Figure 4.2). If instead the page ranks for only its exact target phrase (or nothing), that is a sign the page is thin or narrowly string-focused — a prompt to deepen coverage.

Exercise 4.23

Model response. Reading a full SERP, note the features, because each reveals what Google associates with the query. A knowledge panel means Google has resolved a specific entity and is confident about its facts. A "People also ask" box reveals the related questions (and thus sub-entities and intents) Google ties to the query — a ready-made map of the coverage a comprehensive page should include. "People also search for" and image/video features reveal related entities and formats. Together they tell you the entities, the intent mix, and the topical territory around the query — the answer key for what to build (ties to Chapter 3 and Chapter 10).

Exercise 4.25 †

Rewrite (natural + topically deeper, honest): "Furnace not heating in Cedar Hills? Our licensed HVAC technicians diagnose no-heat calls the same day — from a failed igniter or pilot to a tripped limit switch or a faulty thermostat — and explain the repair and the cost before we start." It reads for a human, drops the robotic repetition, and signals genuine topical depth by naming the concepts that co-occur with real furnace-repair content — while promising a process (same-day diagnosis, transparent cost), not a guaranteed outcome.

Exercise 4.27 †

False/misleading claims and their honest replacements: (1) "LSI keywords" — not a real thing; LSI is a 1990 information-retrieval technique unsuited to the web that Google says it doesn't use. Honest version: cover the concepts a genuine expert would (co-occurrence), because that signals real depth. (2) "ideal TF-IDF density" — there is no magic density; BM25's saturation term means extra instances of a term barely help past a few natural uses. Honest version: write naturally and completely; stop counting. (3) "boost rankings" as a guarantee — no one can guarantee rankings (Google decides against competitors you don't control). Honest version: you improve the odds by being genuinely, comprehensively about the topic. The whole promise trades false precision for the harder truth: understand the subject.

Exercise 4.29

Risk: Wikipedia and Wikidata have community-enforced notability and sourcing standards; a two-year-old company with no independent coverage does not meet them, so a self-created entry is likely to be flagged, edited down, or deleted — and undisclosed paid/self-editing violates Wikipedia's rules, which can attract scrutiny to the brand. Ethical problem: it is an attempt to manufacture corroboration rather than earn it — declaring standing that independent sources don't support, which is the same failure mode as buying links or faking reviews. Honest alternative: build the real signals that create an entity — a substantive About page, consistent NAP and descriptions across legitimate profiles and directories, genuine local coverage and relationships (Chapters 24–25), and real expertise (Chapter 5). Notability, and any Wikipedia presence, should follow from real-world prominence, not precede it.

Exercise 4.30 †

Cooling territory (extension of the Strategy-File map — constructed): (a) Equipment entities: central air conditioner, heat pump, ductless mini-split, condenser unit, evaporator coil. (b) Problem entities: AC not cooling, warm air from vents, frozen evaporator coil, water leaking from the unit, high electric bills / short cycling. (c) Task entities: repair, installation/replacement, refrigerant recharge (and seasonal maintenance/sizing as further tasks). Why it is not yet a keyword list or a content plan: it is a map of things — the entities Rivertown can legitimately be about — not scored search terms and not pages. Keyword research and prioritization turn it into a ranked target list (Chapter 7); the pillar-cluster plan (Chapter 8) and site architecture (Chapter 15) turn it into pages; schema (Chapter 18) marks the entities up for machines. The map is the territory; the campaigns come later.

Chapter 5 — Worked Solutions (daggered † and odd-numbered exercises)

Solutions for the answers appendix. Covers all odd-numbered items plus the daggered ones (5.2, 5.8, 5.16, 5.22, 5.28, 5.30). Hands-on/audit items give a model of a strong answer.

Exercise 5.1

E-E-A-T comes from Google's Search Quality Rater Guidelines, a public rubric for human raters. The letters are Experience (first-hand, lived involvement), Expertise (knowledge and skill), Authoritativeness (recognized reputation among others), and Trustworthiness (accuracy, honesty, safety, transparency).

Exercise 5.2 †

A quality rater evaluates sample results against the Guidelines to help Google measure whether its systems are producing good results; those scores are aggregated to test and tune algorithm changes. They are never applied to the individual pages a rater happens to see. So there is no rater "inspection" of your specific site to pass or fail — the mechanism that would let a rater lower your ranking simply does not exist.

Exercise 5.3

"Experience" captures first-hand, lived involvement that formal expertise misses. Example: a genuine review of a backpacking tent written by someone who actually used it on a trip conveys trust a spec-sheet summary cannot — even if the reviewer holds no credential. Added December 2022, it recognized that for many everyday queries the most helpful source is the person who has done the thing.

Exercise 5.5 †

YMYL = "Your Money or Your Life": topics that could significantly affect a person's health, financial stability, safety, or societal well-being if wrong. Clearly inside: medication dosing, retirement investing, whether a symptom is an emergency. Clearly outside: a cookie recipe, a board-game review. (The point is the stakes: harm potential, not topic difficulty.)

Exercise 5.7

Authoritativeness is "off-page and social" because it is not something you assert about yourself — it is the degree to which others recognize you as a go-to source (citations, mentions, references by name). The strongest machine-readable proxy for it is the link: an editorial link is another site vouching for you, which is why Part IV (links) is largely the study of authoritativeness.

Exercise 5.8 †

Accurate rewrite: "Let's make our site genuinely more trustworthy and make that trust more visible before the next core update." What's wrong with the original: there is no "E-E-A-T score" to raise (Google publishes none; any tool's number is its own invention), E-E-A-T is not a single ranking factor, and framing it as a dial invites bolt-on tactics instead of real improvement.

Exercise 5.9

Model scenario: a famous, credentialed financial advisor runs a widely cited site (high Experience, Expertise, Authoritativeness) that quietly earns undisclosed commissions on the products it recommends and hasn't updated its guidance in years. The failing component is Trustworthiness — and because Trust is the center, the whole assessment is low despite three strong components.

Exercise 5.11

Two distinct reasons to favor the named-contractor page: (1) Verifiability — a reader (and reputation-research signals) can check the license, the address, and the person, whereas the anonymous page offers nothing to verify. (2) Accountability — a named, licensed, locatable business has something to lose by being wrong, which itself is a trust signal. (Note: neither reason proves the second business is technically better; both are trust, not competence, signals.)

Exercise 5.13 †

Four E-E-A-T questions before blaming the content: (1) Is there a named, genuinely credentialed author, and does their reputation check out via independent sources? (2) Is there a real, visible review/editorial process (reviewer, dates, corrections) appropriate to YMYL? (3) What does off-site reputation research say — reviews, mentions, complaints? (4) Have competitors strengthened their trust signals, changing the relative contest? Only after these does "the content itself is weak" become the right hypothesis.

Exercise 5.15

E-E-A-T says the competitor may have become the more trustworthy/authoritative option in Google's estimation, and that a broad quality reassessment (a core update) can shift a relative contest even when your page didn't change. What it does not let you conclude: that the author box/citations caused the gain. Those additions likely travel with a whole bundle of genuine quality improvements; correlation is not causation (Chapter 2).

Exercise 5.16 †

A strong answer is a concrete gap list, e.g.: "Page names no author → add a real bylined owner/technician with credentials; no ownership/address visible → add to footer and Contact; a safety claim has no source → cite or qualify it; can't tell if the '24/7' claim is current → add a last-updated signal." The deliverable is the list of questions the page couldn't answer, converted into tasks — not a score.

Exercise 5.17

Model answer: the student reports what brand + "reviews"/"complaints" surfaces (third-party review profiles, forum mentions, news) and compares it to the site's self-presentation. Strong answers note whether outside reputation corroborates or contradicts the site's claims, and recognize that the outside view is what reputation research (and thus authoritativeness) actually weighs.

Exercise 5.19

The Lowest Page Quality band is reserved for pages that are harmful, deceptive, or untrustworthy — e.g., potential to harm users or society, deceptive design or purpose, malicious behavior, or (on YMYL) content that could seriously misinform. Key insight: a single disqualifying trust failure can put a page at the bottom regardless of other merits — trust is a gate, not an average.

Exercise 5.21

Model answer: the student identifies a YMYL-adjacent query, lists who publishes the top five (established institutions, credentialed authors, recognized brands) and the credibility markers present (credentials, review process, citations, transparency). A strong answer concludes with an honest assessment of what they'd need — often real expertise or a real reviewer — rather than assuming they can match it with formatting alone.

Exercise 5.22 †

Model rewrite: "John Rivera is a CERTIFIED FINANCIAL PLANNER™ with 12 years advising families on retirement and debt. He has led 500+ client financial plans and writes here on budgeting and saving." Annotations: credential → Expertise; years/volume → Experience; specific focus → topical relevance; named person → verifiability/Trust. Why false specifics are a serious mistake: fabricated credentials on YMYL content are deceptive, can harm readers, and are a trust catastrophe if discovered — the counterfeit that sinks the whole page.

Exercise 5.23

A trust-clearing About page skeleton: Who we are (real names/roles → Expertise, Trust); Our story/history (years in business → Experience); Credentials & licensing (license numbers, certifications → Expertise, Trust); Where to find us (addresses, service area → Trust); Reviews/recognition (real reputation → Authoritativeness); How to reach a human (phone, email → Trust). One sentence each is sufficient; substance over length.

Exercise 5.25

Tell the client: those numbers are the tool vendor's model of E-E-A-T, not a Google metric — Google publishes no E-E-A-T score. They can be a rough directional prompt ("we look thinner on trust signals than this competitor") but must never be treated as the thing Google actually measures or as a target to hit. Put roughly zero weight on the exact figures and some weight on the underlying gaps they hint at.

Exercise 5.27

Problems a careful buyer should catch: (1) "raise your E-E-A-T" implies a score that doesn't exist; (2) "guarantee page one" — no one can guarantee rankings (Google decides, competitors vary); (3) the two together promise a mechanical result from a non-mechanical, earned quality. It is the signature of snake oil: precision and guarantees where honesty requires neither.

Exercise 5.28 †

What's wrong: attaching a doctor's name to medical content they did not actually review is deceptive — it fakes the trust signal (a review process) that YMYL readers rely on, and it can lead to real harm. The risk: readers misled on health decisions, reputational and legal exposure, and a fragile ranking that collapses when quality is reassessed. Propose instead: commission genuinely qualified authors, run a real review with real accountability and dates, or don't publish that content at all. Real expertise is the only durable answer.

Exercise 5.29

Incentivized five-star reviews are a liability because they corrupt the very signal reviews are supposed to provide — honest, independent reputation. They violate review-platform policies and Google's guidelines, they are increasingly detectable, and getting caught damages trust far more than the reviews ever helped. It embodies "trust cannot be bought": a purchased reputation is counterfeit. (Review policy, solicitation done right, and the risk of manual actions are covered in Chapters 25 and 26.)

Exercise 5.30 †

Model Rivertown extension: for each branch page — the branch's real street address and local phone (Trust; NAP cleanup deferred to Ch 25); the named licensed lead technician(s) for that location with license numbers (Expertise); years serving that specific community and photos of real local jobs (Experience); real local reviews for that branch (Authoritativeness — engine built in Ch 25). Almost all of this Rivertown genuinely has and simply fails to show. Correctly deferred: the Google Business Profile setup and review-generation engine (Ch 25), and the LocalBusiness/Person schema that expresses these to machines (Ch 18) — deferred because those are distribution and markup layers that should sit on top of legible on-page trust, not substitute for it. Doing them first would be markup over a page that still says nothing verifiable.

Chapter 6 — Worked Solutions

Worked solutions to the daggered (†) and odd-numbered exercises. (Other items are for open discussion or depend on the reader's own site.)

Exercise 6.1

The four shapes of a Google change (§6.1): (1) Routine tweaks — thousands per year, unannounced, individually tiny; ignore them. (2) Broad core updates — a few times a year, announced, a site-wide reassessment of quality and relevance with no single fix. (3) System/targeted updates — built to reward or suppress something specific (Penguin/spam, Helpful Content, Page Experience). (4) New capabilities — not penalties at all, but new ability to understand queries or present answers (Hummingbird, RankBrain, BERT, AI Overviews). The value of the taxonomy is that each shape calls for a different response.

Exercise 6.2 †

Panda (2011) — thin/low-value/content-farm pages. Penguin (2012) — manipulative links + keyword stuffing. Hummingbird (2013) — understanding query meaning. RankBrain (2015) — machine-learning interpretation of queries. "Medic" core update (2018) — broad quality reassessment; YMYL sites felt it. BERT (2019) — natural-language understanding of queries/content. Page Experience (2021) — Core Web Vitals + mobile-friendly + HTTPS + no intrusive interstitials. Helpful Content (2022) — search-first, unhelpful, site-wide content. Spam updates / SpamBrain — link spam, scaled abuse, cloaking, etc. AI Overviews (2024) — AI answers atop the SERP (evolved from SGE, 2023).

Exercise 6.3

Core update — a broad, periodic reassessment of how well pages satisfy searchers; not a penalty. Algorithmic demotion — a ranking drop from an algorithm/update reassessing you; silent (no Search Console notice), reversed only by genuine improvement + time. People-first content — made to genuinely help a real audience (experience/expertise/completeness), vs. search-first content made mainly to catch clicks. Volatility — the constant small day-to-day movement in rankings even between updates.

Exercise 6.5

Panda targeted thin/low-value content (a quality problem) — the content itself was the issue. Penguin targeted manipulation of the link graph — bought links, link farms, keyword-stuffed anchor text (a spam problem) — the off-page signals were the issue. Different families, different mechanisms: one is "your content is thin," the other is "your links are fake."

Exercise 6.7

Broad core updates occur several times a year (historically ~3–4, with no guaranteed cadence). Google's confirmed log lives on the Google Search Status Dashboard (Ranking section) and the "Google Search ranking updates" history page in Search Central. Checking these is the first step of diagnosis (§6.5).

Exercise 6.9

Two errors: (1) "penalized" — a core update is not a penalty; it is a reassessment, and there is usually no violation to find. (2) "file for reconsideration" — reconsideration requests are for manual actions (which come with a Search Console notice), not for algorithmic demotions. Correction: confirm it was actually an update (§6.5), then genuinely improve overall quality and wait for reassessment at a future core update; there is no reconsideration path because no human penalized the site.

Exercise 6.10 †

The four checks in order: (1) Manual-action notice? Yes → it's a manual action (Chapter 26); No → continue. (2) Timing vs. a confirmed update (status dashboard)? No → suspect a technical break/seasonality first; Yes → an update is plausible. (3) Which pages/queries fell? Broad + quality-flavored → core/HCU; pages with manipulative links → spam; one template/section only → suspect technical. (4) Which channel? (GA4) Organic only → consistent with an update; all channels fell → not an SEO update (tracking/outage). Each branch prevents the next mistake.

Exercise 6.11

A single-URL-pattern drop is not typical of a broad core update — updates rarely respect one folder or template so cleanly. Suspect a technical cause instead: an accidental noindex or robots.txt block on that pattern, a canonical error, a broken template, or a redirect problem (Chapter 14). Confirm by inspecting one affected URL in Search Console (is it indexed? served 200?).

Exercise 6.13 †

Recovery is slow because of the mechanism, not Google's cruelty. A core update reassessed the site against an improved standard; nothing was "flagged," so there is nothing to un-flag. The assessment only changes when (a) the site genuinely becomes more deserving and (b) Google re-runs the site-wide assessment and notices — and Google typically does the fuller reassessment with the next broad core update, which may be months away. So even perfect work the day after a drop may not show results until the next update. Recovery is measured in months and updates, not days.

Exercise 6.15

An understanding update (e.g., BERT) improves Google's grasp of what queries and content mean. If your page had been ranking partly because it matched the words of a query — while a competitor better matched the meaning — then as Google's understanding improves, the competitor is now correctly judged the better answer and you drop. You did nothing wrong; Google simply got better at judging, and the truer ranking cost you a position you were arguably never the best answer for.

Exercise 6.16 †

Verdict: a textbook core-update algorithmic demotion. What it shows: organic-only, site-wide, timing-aligned to a confirmed update, no manual action — Google reassessed and judged these pages less deserving than competitors. What it doesn't: it doesn't name which pages to blame, why each was judged weaker, or promise any single edit will restore them; the timing is strong correlation, not proof of causation; and it gives no recovery date. The move: don't hunt a violation or file reconsideration; start a genuine quality program (prune/deepen/strengthen E-E-A-T, §6.6) and begin diversifying traffic (§6.7) so the wait is survivable. The lesson: diagnosis is timing + pages + queries + channel.

Exercise 6.17

The tracker tells you the web weather is rough — lots of sites are moving, so something is happening broadly. It does not tell you that your site was affected, in which direction, or why — and your own flat Search Console says you likely weren't. What you do: nothing reactive. Note it, keep watching your own data, and don't manufacture a problem the tracker only implied. Your data beats a third-party aggregate every time.

Exercise 6.19 †

Rewrite (people-first): "A furnace that won't start usually comes down to one of a handful of causes: no power to the unit (a tripped breaker or a switch that looks like a light switch near the furnace), a thermostat set wrong or with dead batteries, a clogged filter forcing a safety shutoff, or a pilot/ignition problem. Here's how to check each safely in five minutes — and the specific signs (a gas smell, repeated short-cycling, a red blinking status light) that mean stop and call a licensed technician now." Three structural changes: (1) answer the actual follow-up questions searchers ask (cost, DIY-vs-pro, warning signs, when it's an emergency) rather than restating the topic; (2) show genuine expertise/experience — who wrote it, their credentials, real specifics only a technician knows (E-E-A-T, Chapter 5); (3) remove or merge the near-duplicate thin posts elsewhere on the site so the whole domain's quality signal rises (content audit, Chapter 12).

Exercise 6.21

A five-step, 90-day program (not tricks): (1) Diagnose honestly with the E-E-A-T lens + people-first self-assessment — Chapter 5, §6.4. (2) Prune/consolidate dead weight — Chapter 12. (3) Deepen the pages worth keeping into the best answer (comprehensiveness, first-hand detail) — Chapters 4, 9. (4) Strengthen trust signals (real authors, credentials, transparency, sourcing) — Chapter 5. (5) Improve productively and wait for reassessment at the next core update, while diversifying traffic — §6.6–6.7, Chapter 36. Note there is no "disavow" or "reconsideration" step — those don't apply to core-update demotions.

Exercise 6.23

(Reader's own data.) A complete answer cross-references the last three confirmed updates from the status dashboard against the reader's Search Console traffic timeline and writes, per update, whether a move coincided — explicitly separating correlation in timing (defensible) from causation (not proven by timing alone). The skill being practiced is refusing to claim more than the data supports.

Exercise 6.25

(a) Myth — you don't need to react to every update; the right response to nearly all is the same (keep being genuinely useful). (b) Myth — a core-update drop is a reassessment, not a found violation. (c) Myth — no service recovers you fast; there's no button, and the promise is the tell of a scam. (d) Myth — the Helpful Content system targets unhelpful, search-first content regardless of authorship; Google's focus is usefulness, not whether AI was used (Chapter 13).

Exercise 6.27

The plan (swap dates + AI re-spin to "look fresh") is search-first behavior aimed at a signal rather than genuine improvement — exactly the pattern the Helpful Content system and core updates are built to catch. Changing dates without real updates is a fake freshness signal; re-spinning text without adding genuine value or experience produces more unhelpful content. It can make things worse by increasing the volume of low-value pages dragging the site's overall quality signal down. The fix is the opposite: genuinely improve or remove, don't disguise.

Exercise 6.29 †

Rivertown's ~8,000 visits/mo are almost all branded ("Rivertown Home Services"). Nobody is going to outrank Rivertown for its own name in a core update, so its current traffic is incidentally resilient — but only because it barely ranks for competitive, non-branded terms. The book's entire growth plan is to make Rivertown rank for those competitive terms ("furnace repair Cedar Hills," "why is my water heater leaking"), and that traffic is exactly what a future core/helpful-content update can reassess. Implication: the new service×city pages must be built to genuinely deserve to rank — locally specific, useful, distinct — not as thin near-duplicates (the doorway-page trap, Chapters 25/33). Building them right is core-update insurance purchased before the exposure exists.

Exercise 6.31

Suggested Strategy-File entry (one sentence): "Inherited spammy links from the prior vendor are flagged as a known liability; given that Google now increasingly devalues rather than penalizes such links, we take no action yet and defer the explicit disavow-or-ignore decision to the backlink audit in Chapter 26." The point is to record the risk without over-reacting — no premature disavow, which can do more harm than good.

Chapter 7 — Worked Solutions

Worked solutions to the daggered (†) and odd-numbered exercises.

Exercise 7.1

A keyword is a word or phrase people search for, considered as a target you want your content to rank for. A seed keyword is a broad, root term (usually one or two words — "furnace," "water heater") used as the starting point from which you generate more specific keyword ideas. Relation to Chapter 3's query: they are the same underlying thing seen from opposite sides — the searcher types a query (the raw text in the box); the optimizer targets a keyword (that text viewed as something to rank for). And, per Chapter 3, the word is only a clue to the intent behind it — you research words in order to reach wants.

Exercise 7.3

The two questions: (1) what do my customers actually type into Google? and (2) which of those searches can I realistically win? "List the words that describe my business" fails the first because those are the business's words (HVAC services, licensed contractor), not the customer's — customers search their problems in their own words ("furnace won't turn on," "no hot water"). It fails the second because it never asks about winnability at all: it silently assumes every word it produces is worth chasing, when many are unwinnable, low-intent, or both.

Exercise 7.5

(a) "thermostat" = head; "nest thermostat won't connect to wifi" = long-tail → target the long-tail first (specific, winnable, clear intent). (b) "plumber" = head; "kitchen sink draining slowly" = long-tail → long-tail first. (c) "solar panels" = head; "are solar panels worth it in cloudy climates" = long-tail → long-tail first. In every pair, the head is high-volume but brutally contested and vaguely-intented, while the long-tail is lower-volume but winnable for a new site, clearer in intent, and better-converting. A new site starts down the tail and builds toward the head.

Exercise 7.7

A single annual-average volume for "furnace repair" is misleading because the term is violently seasonal — demand spikes in the first cold snap and collapses in summer — so the average hides the peak you must actually prepare for. Publishing to the average risks having your page mature and rank after the season it needed to catch. The free tool to check is Google Trends, which shows the term's interest over time and reveals the seasonal curve, so you can publish and strengthen the page before demand arrives, not in response to it.

Exercise 7.9

This is a winnability failure, not a content or keyword-count failure. "water heater" is a broad head term with an ~82 difficulty; its SERP is owned by national retailers, manufacturers, and major publishers with years of authority a new/small site cannot overtake by adding keywords. Reading that SERP tells you plainly: you are the smallest fish among whales. The better strategy is to abandon the head term for now and target the winnable long tail — specific problems and service×city terms ("water heater making popping noise," "water heater replacement Cedar Hills") — building topical authority across many specific answers so that, over time, the head term becomes reachable. Opportunity = value × winnability, and this keyword's winnability is near zero today.

Exercise 7.11

The blog created keyword cannibalization: "water heater cost," "cost of water heater," "how much water heater," and "water heater price" are one intent ("what will this cost me") phrased four ways, so four near-identical pages compete with each other for the same ranking, split the site's effort and authority, and add thin duplicates a quality system dislikes. The §7.6 fix: recognize (via the same-SERP test — the four queries return largely the same results) that they are one topic, merge them into one genuinely comprehensive page, and map that single page to all four keywords. One want, one page.

Exercise 7.13

(Model answer — a real harvest will vary by business.) A good response shows a genuine alphabet-plus-question harvest of one seed. For seed "water heater," a strong list might include phrasings the business would never have written itself: "water heater making popping noise," "water heater leaking from bottom," "water heater smells like rotten eggs," "how long do water heaters last," "water heater keeps running out of hot water," "water heater reset button," "water heater vs tankless," "no hot water but heater is on," plus PAA questions ("Why is my water heater not producing hot water?", "How much does it cost to replace a water heater?"). The point of the exercise is that Suggest/PAA surface real customer language — specific, problem-shaped, high-intent — that pure brainstorming misses.

Exercise 7.15

(One valid set; intents and value/winnability guesses are illustrative.) From seed "sourdough": - "sourdough bread" — informational/commercial, broad — value MED, winnability LOW (very contested). - "sourdough starter recipe" — informational — value MED, winnability LOW-MED. - "how to feed a sourdough starter" — informational — value LOW-MED, winnability MED. - "best sourdough bread to order online" — commercial investigation — value HIGH, winnability MED. - "buy fresh sourdough bread online" — transactional — value HIGH, winnability MED. - "sourdough bread delivery" — transactional — value HIGH, winnability MED. - "gluten in sourdough bread" — informational — value LOW, winnability MED-HIGH. - "sourdough vs regular bread" — commercial investigation — value MED, winnability MED. For a business whose goal is to sell bread, pursue first the two transactional/commercial terms closest to a purchase — "buy fresh sourdough bread online" and "sourdough bread delivery" — because their searchers are ready to act (highest value) and they are more winnable than the broad head term "sourdough bread."

Exercise 7.16

(One valid expansion and mapping.) From "drain cleaning": - "how to unclog a drain" — informational — DIY how-to topic. - "why is my drain draining slowly" — informational — same how-to/explainer topic (likely one page). - "hydro jetting vs snaking" — commercial investigation — a comparison topic (its own page). - "drain cleaning cost" — commercial investigation — a cost/decision topic (its own page). - "drain cleaning near me" — transactional/local — local service topic (a local-pack fight, Ch 25). - "drain cleaning Northgate" — transactional/local — a service×city page (its own page per city). Mapping: the two informational how-to phrasings → one how-to page; the comparison → one page; the cost query → one page (or a section of the comparison page if the SERPs overlap — apply the same-SERP test); each service×city term → its own local page. "near me" and "[city]" are transactional/local and won largely in the local pack, not by content alone.

Exercise 7.17

(Model answer.) A good response names two similar-looking keywords, searches both (incognito), and compares the top results. If the two SERPs are largely the same pages (for example, "water heater replacement cost" and "how much to replace a water heater" almost always share results), they share one intent → one page targeting both. If the SERPs differ substantially (for example, "water heater" vs. "water heater repair" often return different result types), they are distinct intents → two pages. The exercise's point: let Google's own results — not word similarity or intuition — decide grouping, exactly as Chapter 3 reads intent off the SERP.

Exercise 7.18

Group and map: - "furnace won't turn on," "furnace not working," "furnace stopped working" → one intent (a furnace that has died; the owner wants to diagnose/fix it now) → one troubleshooting page (leads with likely causes and a clear "call a pro" path). - "furnace repair cost," "how much furnace repair" → one intent (cost/decision) → one cost page. - "furnace repair near me" → transactional/local intent → a local service page, and note this is largely a local-pack fight (GBP, proximity, reviews — Chapter 25), not a content fight. One want, one page; three pages total, not six. The "near me" term is the local-pack one.

Exercise 7.19

Sorting purely by descending volume is wrong because it ignores both factors of opportunity: winnability (the biggest terms are usually the least winnable — head terms owned by national brands) and value-by-intent (a high-volume informational term can be worth less than a low-volume transactional one). It sends your effort to the top of a list of fights you will mostly lose. Rewritten conceptually with opportunity = value × winnability: put the high-value, winnable terms first (specific, high-intent, service×city and long-tail terms with weak SERPs), treat high-value, low-winnability head terms as the long game, use low-value, winnable terms as cheap coverage, and skip low-value, low-winnability terms — regardless of raw volume.

Exercise 7.21

• THE QUERY / PAGE: Rivertown's Search Console Performance report, two striking-distance rows.
• WHAT'S THERE: "how to relight furnace pilot light" — 900 impressions, 30 clicks, avg position 9; "water heater replacement cost" — 1,400 impressions, 11 clicks, avg position 12.
• WHAT IT SHOWS: Google already deems both pages relevant enough to show near page one — proven demand and proven relevance. The cost page (position 12, high impressions, very low clicks) is especially ripe: a small gap to page one on a high-value commercial term.
• WHAT IT DOESN'T: it doesn't say why each sits where it does (weak title? thin content? stronger competitors? intent mismatch?), nor guarantee that improving the page will move it — Google decides. It only covers terms the site already appears for.
• THE MOVE: prioritize improving the pages behind these striking-distance queries (better intent match, comprehensiveness, internal links — Chapters 9 and 15) before chasing brand-new terms.
• THE LESSON: your own Search Console is the first and best keyword tool you own — mine what you nearly rank for before hunting what you don't rank for at all.

Exercise 7.23

Everything is wrong on two counts. (1) It is not from Google — Google publishes no difficulty score; every "KD" number is a proprietary vendor estimate, computed differently by each tool (mostly from the backlink profiles of ranking pages), which is why the same keyword scores differently across tools. (2) It is not objective for you — the score estimates difficulty for an average site, not for your site with your authority in your niche. The reliable way to judge difficulty is to read the SERP: open the results and look at who actually ranks. Weak incumbents (forums, thin/outdated blogs, intent-mismatched pages) mean an opening; a wall of national brands, or a local pack, means a harder or different fight. The score narrows the field; your eyes make the call.

Exercise 7.24

The rebuttal: the entire free toolkit — Google Search Console (your own real queries and striking-distance terms), Keyword Planner (Google's own volume ranges and ideas), Google Suggest and People Also Ask (real live phrasings and questions), AnswerThePublic (Suggest visualized), and Google Trends (seasonality/trajectory) — plus reading SERPs by eye produces an actionable keyword list at no cost, enough for a small business for a year. What a paid tool (Ahrefs/Semrush) adds is specific: scale (thousands of terms instantly), competitor and keyword-gap analysis (every term a competitor ranks for that you don't — the real superpower, Chapter 30), backlink data, and automated rank tracking. Those buy speed and competitive intelligence, not Google's real data and not a strategy — and they matter once your time is the scarce resource, not before. "Can't start without Ahrefs" is false.

Exercise 7.25

This is the keyword-factory error (Case Study 7.2) and it fails on three fronts. Intent (Chapter 3): targeting terms by volume alone, regardless of whether the business can satisfy the intent, guarantees intent-mismatched pages that don't rank durably. Winnability (this chapter): the highest-volume terms are usually the least winnable, so most of the 500 pages are fights the site can't win. Quality/Helpful-Content risk (Chapter 6): mass-producing thin pages to chase volume is precisely the "search-first, scaled" pattern quality systems demote site-wide — it is a liability, not an asset, and one core update can collapse it. The honest alternative: research demand rigorously, then build a smaller number of genuinely useful pages prioritized by opportunity (value × winnability), winning the high-intent long tail and building topical authority toward the bigger terms over time.

Exercise 7.27

(Model answer — bands illustrative.) - "why is my AC blowing warm air" — informational (Know); VALUE MED (leads to summer repair calls), WINNABILITY HIGH (weak SERP: forums and thin blogs) → ✔ QUICK WIN: an expert troubleshooting page (with a "call us if it's the compressor" path). - "electrical panel upgrade Westbrook" — transactional/local; VALUE HIGH (a big-ticket job, ready to hire), WINNABILITY MED (local-pack + a genuinely local service×city page) → ★ DO FIRST: a real, distinct Westbrook panel-upgrade page plus local-pack work (Chapters 25/33).

Exercise 7.28

"furnace repair [city]" (e.g., "furnace repair Cedar Hills") is a long-tail, high-value, winnable opportunity because it is specific (clear transactional/local intent — someone in that city who needs a furnace fixed), high-value (ready to hire), and winnable (a genuinely local page plus local-pack presence competes against relatively few, often-weak local results). "furnace repair" with no city is a near-head term: broad, lower-intent, and contested across an entire metro or nation by far stronger sites, with low winnability for a single business. The two later chapters that decide how the city pages get built without becoming doorway spam are Chapter 33 (Programmatic and Enterprise SEO) — the service×city page system at scale — and Chapter 25 (Local SEO) — the local-pack and NAP dimension. (Architecture support is Chapter 15.)

Exercise 7.29

(Two-sentence model.) "'hvac' has the biggest volume precisely because it is the vaguest term in the industry — its searchers could want anything (a definition, a career, a brand, a system to buy), so even if we ranked for it the traffic wouldn't convert, and we can't rank for it anyway against national brands and manufacturers. Let's instead target the specific, high-intent searches your actual customers type — 'furnace repair Cedar Hills,' 'AC not cooling,' 'water heater replacement cost' — where the searchers are ready to act and we can realistically win." (Value × winnability both fail for "hvac"; both succeed for the specific terms.)

Exercise 8.1

A topic cluster is a group of interlinked pages that together cover one subject comprehensively. The pillar page is the broad hub: it covers the core topic at a high level and targets the head term (e.g., furnace problems). Cluster content are the narrower spoke pages, each covering one specific facet in depth (e.g., furnace blowing cold air). The single structural element that turns a set of pages into a real cluster is internal linking — the pillar links down to every spoke and each spoke links back up to the pillar (and across to siblings where relevant). Without the links, it is just a pile of pages, not a cluster.

Exercise 8.3

A content gap is a valuable topic or query that competitors rank for and your site doesn't cover, covers thinly, or covers with the wrong intent. The three flavors: - Topic gap — no page exists for the query (you don't compete at all). Example: competitors rank for "furnace short cycling"; you have no page on it. - Coverage gap — a page exists but is thinner than the pages outranking it, missing subtopics they all cover. Example: your furnace page never mentions the flame sensor, the most common real cause. - Intent gap — a page exists but targets the wrong intent for the query. Example: you wrote a "how it works" explainer for a query whose SERP is dominated by comparison pages.

Exercise 8.4 †

Content velocity is the rate at which a site publishes new content — posts per week or per month. What it is: a symptom of a large, capable content operation (big authoritative sites tend to publish a lot). What it is not: a ranking factor. Publishing more frequently does not, by itself, raise rankings; Google has stated there is no reward for a posting schedule. The correlation between high-volume sites and good rankings runs through capability and quality, not cadence — copy the cadence without the capability and you get the 500-post blog.

Exercise 8.5

Minimum useful fields for an editorial-calendar row: (1) target topic / primary query, (2) primary intent, (3) content type/format, (4) cluster and role (pillar or spoke), (5) owner (a single named person), (6) due date and status, and (7) priority. The field that comes from Chapter 7's work is priority — the opportunity score (value × winnability) that decides sequencing, so you build the high-value, winnable pages first rather than guessing.

Exercise 8.7

"A content plan is inseparable from a site-architecture plan" means that deciding what to publish is, at the same moment, deciding how it connects. The pillar-cluster model is realized entirely through internal links — the pillar links down to the spokes, the spokes link up to the pillar — so the content decision (these pages form a cluster on furnaces) is simultaneously an architecture decision (how pages link and how authority flows through them). You cannot design one without designing the other. The chapter that builds the architecture side — internal linking, hub-and-spoke, link equity — is Chapter 15.

Exercise 8.9 †

Every one of the 300 gaps must pass Chapter 7's two prioritization questions before earning a calendar slot: Is it valuable? (does the searcher for this query plausibly become a customer, subscriber, or link — or is it idle curiosity with no path to a result?) and Is it winnable? (can a site with your authority realistically rank against who already ranks?). Writing all 300 would likely lower the site's traffic because most would be thin, low-value pages produced to hit a number; since the Helpful Content system judges quality largely site-wide, a flood of thin pages drags down the average quality signal and can pull down your good pages too. A gap is a candidate, not an assignment — filter first.

Exercise 8.11

You build the pillar early and sequence by cluster because a cluster is stronger than the sum of its pages precisely because of the internal links among them. Publishing the pillar (or a solid draft) first gives every subsequent spoke a hub to link up to, and lets you update the pillar to link down to each new spoke — so the cluster reads, to both readers and Google, as a coherent body of work rather than scattered posts. A "minimum viable cluster" (pillar + the two or three highest-priority spokes shipped close together) makes the structure legible fast. The ordering buys you a real, interlinked structure on purpose instead of a random walk through your keyword list.

Exercise 8.13

"A gap is a candidate, not an assignment" separates a strategist from a tool-operator because the tool's report is a list of possibilities — every keyword a competitor ranks for and you don't — with no judgment attached. The operator dutifully turns all of them into articles (and builds the 500-post blog). The strategist runs each candidate through value × winnability and relevance to the business, keeps the few that fit a real intent and a real chance of ranking, and consciously discards the rest. The discarding is the skill: it keeps the site's average quality high, which is itself an asset. Strategy is deciding what not to build.

Exercise 8.14 †

The problem is keyword cannibalization: three pages ("Best Furnace Brands 2026," "Top-Rated Furnaces," "Furnace Brand Comparison") all target the same query and the same primary (commercial) intent, so they split internal links, authority, and Google's attention, and trade places in the 6–15 range because Google keeps picking among them without any one being strong enough to break the top five. The fix is to consolidate: merge the three into a single, comprehensive best-furnace page (keeping the strongest URL, redirecting the others — the mechanics are Chapter 12), so one strong page inherits the combined signals instead of three weak ones competing. One job, one page.

Exercise 8.15

"Everything About Furnaces" fails the one-primary-intent rule: it tries to serve four different searchers at once — a buyer comparing brands (commercial), a homeowner fixing a problem (informational), someone pricing a repair (commercial/cost), and someone ready to book (transactional) — who each want a genuinely different page. Google, reading the SERP for each of those queries, sees a page that matches none of them dominantly, so it ranks well for none. Split it into: a buying/comparison guide (commercial), one or more troubleshooting/how-to articles (informational, likely a whole cluster), a furnace repair cost page (commercial), and a service/booking page (transactional) — then interlink them as a cluster, with the transactional page living in the core service architecture, not the blog.

Exercise 8.16 †

The failing stage is discovery (Chapter 1): nothing links to the new page and it isn't in the pillar, so it is an orphan — Google has no reliable road to it, and even excellent content can't rank if it isn't found and indexed. This chapter's model prevents it by construction: a page created as part of a cluster is, by definition, linked from its pillar (and to it), so a properly built cluster has no orphans. The content plan and the architecture are the same plan (§8.1), and building the internal links is Chapter 15's job — but the decision to wire this spoke into the cluster was made the moment it went on the map.

Exercise 8.17

Turning an 80-post structureless blog into clusters without publishing anything new first, in five steps: (1) Inventory — list all 80 posts with their current traffic and target query (a mini content audit, front-loading Chapter 12). (2) Group into topics — cluster the posts by subject to reveal the two or three real themes hiding in the pile. (3) Spot cannibalization — within each group, find posts competing for the same query; mark them to merge later. (4) Designate pillars — pick or plan a hub page for each theme (an existing strong post can become the pillar, or you note one to write). (5) Wire internal links — link the related posts to their pillar and to each other, turning existing scattered posts into real clusters. Only after this do you decide what genuinely new pages the gaps require.

Exercise 8.19 †

The failure is an intent mismatch (Chapter 3): the page's type/intent (a "how a furnace works" informational explainer) does not match the query's dominant intent (a commercial decision — repair or replace?), which the SERP reveals by being full of comparison/decision pages. The fix is almost always a different page built specifically for the comparison intent, not a rewrite of the explainer. The explainer may still legitimately serve its own informational query ("how does a furnace work"); rewriting it to chase the comparison query would just abandon one intent to poorly serve another. One page, one intent — so the comparison query gets its own, correctly-typed page.

Exercise 8.21 †

(Guided — answers vary by site.) A correct deliverable is a pillar target plus five to eight spokes, each tagged with one primary intent, that pass both checks. Example (for a hypothetical roofing site): Pillar → "Roof Leaks: Causes, Fixes & When to Call a Pro" (informational, head term). Spokes → "roof leak around chimney" (info), "roof leak in heavy rain only" (info), "how to find a roof leak" (info/how-to), "roof leak repair cost" (commercial), "repair or replace a roof" (commercial). Checks: no two spokes share an intent ✓; the transactional "roof repair [city]" / "emergency roofer near me" queries are routed to a service/location page, not a blog post ✓. If you cannot find at least four genuinely distinct sub-questions people search, the subject may be one strong page, not a cluster — don't force spokes.

Exercise 8.23

(Guided.) The deliverable is a keep/merge/delete call for one pair of same-query pages, with a justification. Example: "Pages /water-heater-repair and /fixing-your-water-heater both target 'water heater repair'; they cannibalize. Merge into /water-heater-repair (it has more links and traffic), 301-redirecting the other." The single check that confirms it: in Search Console, look at which URL Google actually shows for the query and whether they swap — flip-flopping between two of your own URLs is the signature of cannibalization. The full method (and the redirect mechanics) is Chapter 12; here, the call and its reasoning are the point.

Exercise 8.24 †

(Guided — a model answer.) Seed "furnace" expanded via Google Suggest + People Also Ask into a cluster: - Pillar: "Furnace Problems: A Homeowner's Troubleshooting & Repair Guide" — informational, broad head term. - Spokes (informational cluster articles): furnace blowing cold air; furnace not turning on; furnace short cycling; furnace making a [banging/squealing] noise; how to relight a pilot light safely; furnace smells like burning. - Spokes (commercial): furnace repair cost; repair or replace a furnace. - Route elsewhere (transactional, NOT blog posts): "furnace repair [city]" and "emergency furnace repair" → service/location pages (Chapters 25, 33). The cluster links to these but does not duplicate them. Each page carries exactly one primary intent; close variants ("furnace won't start," "furnace won't kick on") map onto the single "furnace not turning on" page rather than becoming separate pages.

Exercise 8.25

(Guided.) A model seven-row calendar for the 8.24 cluster, sequenced pillar-first then by priority: 1. Furnace Problems (PILLAR) — guide — pillar — build first — owner: lead/SME. 2. Furnace not turning on — troubleshooting — spoke — high (high intent, seasonal) — writer. 3. Furnace blowing cold air — how-to — spoke — high — writer. 4. Furnace repair cost — cost guide — spoke — high (commercial) — writer. 5. Repair or replace a furnace — comparison — spoke — medium — writer. 6. Furnace short cycling — troubleshooting — spoke — medium — writer. 7. How to relight a pilot light safely — how-to — spoke — medium (needs careful SME/safety review) — writer + technician. The pillar and the two highest-priority spokes ship first (a "minimum viable cluster"); each row names an owner and a status, and priority is inherited from Chapter 7's opportunity scoring.

Exercise 8.27 †

Row by row: "furnace flame sensor" — a topic gap (no page), high value (people with this problem often need a pro), winnable (competitors rank locally); a strong candidate. "how long do furnaces last" — a topic gap but the trap: high volume, low commercial intent (idle curiosity rarely converts to a booked job), and easily an editorial time-sink; deprioritize or skip. "furnace repair near me" at #14 — not a blog gap at all; it's a transactional/local query that belongs to a service/location page, and #14 signals a local-SEO/architecture problem (Chapters 25, 33), not a missing article. "best furnace 2026" — a topic gap, commercial, but low volume and leans editorial/affiliate; lower priority for a service business. Prioritize first: "furnace flame sensor" — real problem, real intent, winnable, on-topic. The trap row is "how long do furnaces last": tempting volume, little payoff.

Exercise 8.29 †

The myth is that publishing volume is Google's top growth lever ("a new post every business day"). What's actually true, sorted: False — publishing frequency is not a ranking factor; Google has said there's no bonus for a posting schedule, and "active/fresh site" is not a general ranking boost (genuine freshness matters only for time-sensitive queries). Grain of truth — consistently producing good content does compound (more quality pages entering the index over time). Replacement rule: publish as often as you can while keeping every piece genuinely worth ranking — quality sets the cadence, not a quota. For most teams that's a few strong pieces a month, not one weak piece a day; the daily-post version manufactures the 500-post blog.

Exercise 8.30 †

The real risk (not just "it won't help"): since the Helpful Content system, a burst of 100 fast, generic, unreviewed posts is not neutral filler — it is a site-wide liability. Google's quality assessment is largely site-wide, so a pile of thin, experience-free, search-first pages can drag down the rankings of the site's good pages too, and the damage is slow to reverse because reassessment takes months (Chapters 6 and 13). So the "impress the investor" sprint can measurably harm the asset it was meant to showcase. The honest alternative deliverable in the same quarter: one genuinely excellent pillar-and-cluster (say 8–10 deep, technician-reviewed pages on the highest-value subject) plus an audit/update pass on existing content — a real, defensible content asset you can show an investor, built to compound rather than to poison the site.

Exercise 8.31

(Guided — Rivertown Strategy-File extension.) A model second cluster (cooling): Pillar → "Air Conditioner Problems: Troubleshooting & Repair Guide" (informational, head term). Spokes → "AC not cooling" (info), "AC blowing warm air" (info), "AC frozen coil / ice on AC" (info), "AC making noise" (info), "AC repair cost" (commercial), "repair or replace an AC" (commercial). Hand off to service/location pages (Chapters 25, 33), not blog posts: "AC repair [city]," "emergency AC repair near me." Each spoke has one primary intent; the cluster interlinks (pillar ⇄ spokes) and links to the AC service page; it mirrors the furnace cluster's structure, so Rivertown builds a repeatable pattern across HVAC, plumbing, and electrical rather than reinventing it each time.

Exercise 9.1

The title tag is the HTML <title> in the page's <head>; it is (usually) the clickable headline in the SERP and the browser-tab text, and it is one of Google's signals for what the page is about. The meta description is the <meta name="description"> that proposes the snippet under the title. Ranking: the title tag is a ranking signal (and a big CTR lever); the meta description is NOT a ranking factor — it only influences click-through when shown. What each is for: the title earns the click and helps relevance; the description is pure ad copy for the listing.

Exercise 9.3 †

Keyword density is the (discredited) idea that a target percentage of keyword occurrences improves ranking — occurrences ÷ total words. Keyword stuffing is the practice it leads to: cramming a keyword unnaturally to inflate that frequency. Google's treatment: keyword density is a non-factor (there is no target ratio; Google does not reward one), and keyword stuffing is a negative signal — named explicitly in Google's spam policies as manipulation that can hurt a page. So one is folklore, the other is actively harmful.

Exercise 9.5

Above the fold is the part of a page visible before the reader scrolls (from the newspaper term for the top half of the front page). What belongs there on a question-answering page: the core answer itself — the cost range, the timeline, the direct yes/no-with-nuance — so a searcher sees the answer immediately (the answer-early / inverted-pyramid principle), before any preamble or company history.

Exercise 9.7 †

The title is highest-leverage because it does two jobs at once: (1) it is a relevance signal — Google uses the <title> to understand what the page is about — and (2) it is the click lever — it is the SERP headline that decides whether a searcher who sees your result actually chooses it over a competitor's. Most on-page changes help one thing; the title helps ranking and click-through, and you can usually rewrite it in five minutes on a page that already earns impressions. That ratio of effort to potential payoff is unmatched — though it remains a lever, not a guarantee.

Exercise 9.9 †

It is wrong on two counts. (1) On ranking: the meta description is not a ranking factor at all, so keyword-stuffing it to "help rankings" accomplishes nothing — you are optimizing a non-signal. (2) On its actual job: the description's only job is to earn the click when Google shows it, and a keyword-stuffed description reads like spam, which lowers click-through — so the tactic is not merely useless, it is counterproductive to the one thing the description is for. Write it as human ad copy instead.

Exercise 9.11

Two parts. (1) Language understanding: modern Google understands meaning, not just string matches — BERT and other NLP systems grasp context and synonyms (Chapters 2, 4), so once a page clearly covers a topic, repeating the exact phrase adds nothing. (2) Retrieval math: the information-retrieval scoring behind term matching — TF-IDF and BM25 (Chapter 4) — deliberately gives diminishing returns to repetition and normalizes by document length, so a page cannot win by brute-forcing term counts. The math is built to defeat stuffing.

Exercise 9.13 †

Inspect the title tag and meta description first. A page at ~#8 that earns thousands of impressions is already ranking well enough to be seen — the failure is that people see it and don't click, which is a CTR problem, and CTR is governed almost entirely by the headline (title) and the snippet (description). It is not a "write more content" problem because more content changes what happens after a click, not whether the click happens; adding words here would be effort spent on the wrong stage. First move: rewrite the title to match intent and the description to earn the click, then watch CTR in Search Console.

Exercise 9.15 †

The principle violated is answer-early / the inverted pyramid: the page makes the searcher wade through a company history before delivering the answer they came for. The fix: move the direct answer ("most water-heater replacements take about two to three hours") to the top of the page, above the fold, in the first paragraph — then keep the detail and the company background below it in descending order of importance. Sequencing, not deletion: the history can stay; it just cannot come first.

Exercise 9.17 †

A rewrite that matches the "why is my water heater leaking" intent (a worried person diagnosing a problem): "Why Is My Water Heater Leaking? Common Causes & What to Do | Rivertown" Two main changes: (1) the title now answers the searcher's actual question (diagnostic intent) instead of listing the company's service lines — it leads with the question the searcher typed; and (2) the brand is trimmed and moved to the end ("| Rivertown"), and the vague "Serving You Since 1984" boilerplate is dropped, so the meaningful, intent-matching words are front-loaded and the title survives truncation. It is specific and truthful — no stuffing.

Exercise 9.19

A logical hierarchy that also answers early: - H1 — Water Heater Replacement Cost: What You'll Actually Pay - (opening, above the fold) the answer: the typical total installed range - H2 — What goes into the cost (labor + unit + permits) - H3 — Unit price: tank vs. tankless - H3 — Labor cost - H3 — Permit fees - H2 — Cost by fuel type (gas vs. electric) - H2 — When replacing beats repairing The core answer (typical total range) sits first; the breakdown descends from most to least important.

Exercise 9.21 †

Four free places to find follow-up questions: (1) the "People Also Ask" box on the SERP; (2) Google Suggest / autocomplete; (3) the "related searches" at the bottom of the results page; (4) Search Console's query report (the real questions already bringing impressions). The source that is free, underused, and unavailable to competitors: your own customers / frontline staff — for Rivertown, the service technicians, who answer every real homeowner question all day and know the ones no keyword tool surfaces.

Exercise 9.23

Turning the PAA questions into reader-phrased H2s: - H2 — How much does it cost to replace a water heater? - H2 — How long does a water heater last (and when should you replace it)? - H2 — Can you replace a water heater yourself? - H2 — Tank or tankless: which is right for your home? (Each is phrased the way a searcher would ask it, which doubles as featured-snippet fodder.)

Exercise 9.24 †

Four bundled myths. (1) "Repeat your exact keyword in the first sentence" — keyword-position folklore; write naturally, use the term where it fits. (2) "in every single heading" — headings should phrase the reader's real questions, not repeat one phrase; identical keyword-headings read as templated and invite title rewrites. (3) "three times in the meta description" — the meta description is not a ranking factor and stuffing lowers CTR; write it as ad copy. (4) "never publish under 1,500 words" — word count is not a ranking factor; length should match what the answer honestly requires. The unifying truth: write for the reader and cover the topic; every one of these myths substitutes a ritual for that.

Exercise 9.25

This is hidden text (also called cloaking-adjacent hidden content) — text placed so visitors can't see it (here, matching the background color) but crawlers can. It violates Google's spam policies, which explicitly prohibit hidden text and deceptive practices, and it risks a manual action or algorithmic demotion (Chapters 6, 26) — a real business risk, not a clever edge. What you tell the client: we don't do it, both because it's against the guidelines and because it's the anti-pattern of this whole approach — if the content is worth having, put it visibly on the page where it serves readers; if it isn't worth showing a human, it isn't worth showing a crawler. The honest lever is comprehensiveness the reader can see.

Exercise 9.27 †

Title tag: "Water Heater Replacement: Cost, Signs & Tank vs. Tankless | Rivertown" Meta description: "What a new water heater costs, the signs yours is failing, and how to choose tank vs. tankless — plus same-week replacement across the Rivertown metro." (~150 characters) The title leads with the decision the searcher is weighing (matching the informational/commercial intent Chapter 3 diagnosed), keeps the brand trailing, and does not stuff "water heater." The description is ad copy: it names the three things the searcher wants (cost, signs, choice), then offers a reason to click (same-week service, local). Neither is a keyword dump; both are honest and specific.

Exercise 9.29 †

Reframe for Tony: "The competitor doesn't win because the page is longer — it wins because it's more complete. Length is a side effect of covering the topic, not the reason it ranks; Google has said word count isn't a ranking factor, and padding our page with a thousand filler words would actually make it worse by burying the answer. Instead of adding words, let's add coverage: the specific questions our customers ask that our page doesn't answer yet — what it costs, the signs you need one, tank vs. tankless, whether you can DIY it, how long it takes and whether you need a permit. Your technicians answer those every day; let's write those answers down. That's comprehensiveness, and it's what actually competes."

Exercise 10.1

A content format is the shape a piece of content takes — a how-to guide, an explainer, a listicle, a comparison, a tool, a video, a service page — chosen to match what the searcher is trying to do, not what the page is about. "A blog post is a container, not a format" means that /blog/ is just a place a page lives; a blog post can hold a how-to, a comparison, a listicle, or a tool, so saying "let's write a blog post" tells you nothing about whether the content matches the query's intent — the useful question is "what format does this query want?", and a blog post is merely one possible place to put the answer.

Exercise 10.3 †

A SERP feature is any element on a results page that is not a standard organic blue-link listing. Six examples and what each signals: (1) Featured snippet — Google has a concise, extractable answer; the query wants a direct answer in that shape. (2) People Also Ask — the query has common follow-ups; informational depth is wanted. (3) Local pack (map + businesses) — local/transactional intent; a service or store page, not an essay. (4) Video pack/carousel — the query is well served by watching (how-to, review). (5) Image pack — visual intent (what something looks like, designs, diagrams). (6) Shopping results — commercial/transactional product intent. (Others: knowledge panel = an established entity; sitelinks = a strong brand/navigational result.)

Exercise 10.5

(a) "what is a heat pump" → what-is / explainer (paragraph snippet). (b) "how to bleed a radiator" → how-to / step-by-step (list snippet), often with a video. (c) "tankless vs tank water heater" → comparison page with a table. (d) "furnace repair near me" → local service / landing page (local pack is the real battle). (e) "how many BTUs to heat 1,500 sq ft" → interactive tool / calculator (or a cost/sizing guide with a calculator).

Exercise 10.7

Over billions of searches, Google observes which page shapes satisfy which query patterns — people who type "how to…" stay on step-by-step pages and quickly leave sales pages; people typing "X vs Y" stay on comparison tables and leave essays. Pages in the satisfying shape accumulate the engagement patterns that correlate with ranking, so the results page for a query fills up with that shape. Building that shape therefore isn't an aesthetic choice; it's supplying the form Google has already learned that this kind of searcher is satisfied by — which is why you can read the required shape directly off what already ranks.

Exercise 10.8 †

Two reasons length is the wrong instinct: (1) Format, not length, is what matches intent — a 4,000-word essay loses to a tidy comparison table when the query wants a comparison, and to numbered steps when it wants a how-to; extra words in the wrong shape actively hurt. (2) The "ideal word count" is a myth (Chapter 9) — there is no length Google rewards as such; long pages that rank are usually long because the topic genuinely needs it, not the reverse. What actually determines whether length helps is comprehensiveness: covering what the searcher needs (the real subtopics, often visible in People Also Ask), sized to the job — never padding to hit a number.

Exercise 10.9

Winning a featured snippet can reduce clicks when the snippet fully answers the query, so the searcher reads the answer in the box and never clicks through — the zero-click pattern. This is most likely for fact/definition queries where a short, complete answer satisfies the need ("how many ounces in a cup," "what time is it in Tokyo," a simple "what is X"). A snippet most likely helps for queries where the box is a teaser — the first few of many steps, a definition that invites depth, a comparison the reader wants to explore — where being at the top of the page with a partial answer pulls the click.

Exercise 10.11

A well-built tool punches above its weight because it has two advantages prose usually lacks: (1) it matches high-intent queries more precisely — someone asking "what size furnace do I need" wants a number for their situation, which a calculator delivers and an article can only approximate; and (2) it is highly linkable — other sites (journalists, blogs) cite a useful tool instead of re-deriving the math, so it earns backlinks that compound, whereas an equally useful article gets read and forgotten. So a tool is simultaneously an intent-match and an authority-earning asset — the rare format that does both.

Exercise 10.13 †

As structure: the People Also Ask questions are the real follow-up questions searchers ask, effectively a ranked subtopic map — each becomes a candidate section heading, turning "what should this page cover?" from a guess into a reading exercise (and expanding questions loads more). As opportunity: the answers inside the box are extracted from ranking pages the same way featured snippets are, so answering each question concisely under a matching heading makes the page eligible to be pulled in (never guaranteed). The caution: don't mechanically bolt a keyword-matched FAQ of every PAA question onto the bottom of the page — cover the questions in the page's natural flow, where they belong, rather than staging them for the machine.

Exercise 10.15 †

Build a diagnostic guide ("furnace short cycling: causes and fixes") — a "causes and what to do" format, because the top ten are all diagnostic guides and that is the dominant shape. To be eligible for the paragraph featured snippet present on that SERP, give a concise, direct answer to "why is my furnace short cycling" (a 40–60 word summary of the common causes) right under a heading that matches the question, near the top of the page. That earns eligibility, not a guarantee. Use the People Also Ask questions as the section structure (dirty filter, thermostat placement, oversized furnace, flame sensor, when to call a pro), and end with an honest "when to call a technician" bridge.

Exercise 10.16 †

Honest decision: do not target "best smart thermostats" as a direct ranking goal. The SERP shows it is held by high-authority review publishers and consumer-advice sites with huge link profiles; a small local HVAC company cannot out-authority them no matter how good its roundup is (Gate 2, §10.7). Instead, aim the effort at winnable, experience-rich queries where a local installer is the authority — "which smart thermostat works with my old furnace," "smart thermostat installation [city]," "do I need a C-wire for a smart thermostat" — and, if you want to mention brands, do it inside those genuinely first-hand pages. Chasing the head "best" query is a format trap; owning the long-tail, local, experience-specific queries is a winnable strategy.

Exercise 10.17

"AC repair Cedar Hills" wants a local service / landing page, not an article: the SERP shows a local pack and organic service pages, which is Google signaling transactional-local intent. The real battle here — the local pack (map + three businesses) — is owned by Chapter 25 (Local SEO): Google Business Profile, reviews, NAP consistency, and proximity/prominence. The organic service page still matters (clear service + city relevance, click-to-call, speed), but the format is a landing page, and the highest-value real estate is the map pack.

Exercise 10.19 †

The mixed SERP shows the query "water heater replacement" carries multiple intents at once: transactional-local (service pages + local pack), commercial-investigation (cost guides), and informational-DIY (how-to guides). The read: no single page can be the ideal answer to all three. Rather than build one compromise page that serves none well, build separate, intent-matched pages — a local service page for the transactional query (the money page, tied to the local pack, Ch 25), a cost guide/calculator for "cost to replace…", and a how-to for the DIY searchers — each in its own format, interlinked. The mixed SERP is Google telling you the keyword is really several jobs; split them by intent (this also avoids cannibalization, Chapter 12).

Exercise 10.21 †

(Guided — answers vary by site.) The deliverable is a completed six-field Read-the-SERP block for one chosen query plus a one-sentence mismatch check. Example mismatch sentence: "The SERP for 'tankless vs tank' is all comparison tables, but our page is a 2,000-word narrative essay with no table — format mismatch; rebuild as a side-by-side comparison with a table." A match is equally valid to record ("SERP wants a how-to; our page is a how-to — proceed"). The point is to catch a format mismatch before writing, not to fix it yet.

Exercise 10.23

(Guided.) Identify one page whose format fights its query's intent — common cases: a sales/service page targeting an informational query ("how to relight a pilot light" pointed at a "book now" page), or an essay targeting a comparison query (prose where the SERP wants a table). Describe the mismatch ("the query wants steps + a video; the page is a service pitch") and name the rebuild format ("a step-by-step how-to guide with a short video, with a soft service CTA at the end"). Diagnose only; the rebuild is Chapter 9's craft.

Exercise 10.25 †

• "how to relight a pilot light" → informational, procedural → how-to (list/steps); expect a list featured snippet and possibly a video pack. Verify by searching and counting steps-format results.
• "tankless vs tank" → commercial investigation → comparison page (table); expect a table snippet and a PAA box.
• "cost to replace a furnace" → commercial investigation → cost guide, ideally with a calculator; expect a paragraph/table snippet with a price range and a PAA box.
• "signs of a failing water heater" → informational → listicle ("N signs…"); expect a list snippet and a PAA box.
• "24 hour plumber near me" → transactional, urgent, local → local service/landing page; expect a local pack dominating (verify: map + businesses at the top, click-to-call).

Exercise 10.27

Two false claims. (1) "Featured snippets are won by adding schema markup" — false; snippets are selected algorithmically from pages already ranking on page one, and no markup forces one (schema governs rich results, a different feature, Ch 18). Truth: you earn eligibility by ranking on page one and answering concisely in the matching format under a matching heading. (2) "The longer and more comprehensive your page, the more snippets you'll win" — false; length is not a snippet lever, and comprehensiveness only helps within the right format. Truth: the shape of the answer (paragraph/list/table) matching the shape of the question is what makes a page snippet-eligible — a concise, well-formatted answer beats a long one.

Exercise 10.28 †

This is both a format trap and an unkeepable promise. Format trap: "best [product]" roundups are the right format for commercial intent, but for a brand-new site they fail Gate 2 — those queries are owned by high-authority review publishers, and 500 experience-free pages don't overcome an authority gap; worse, mass-produced roundups with no first-hand experience are precisely what Google's Helpful Content and reviews systems demote (Case Study 2). Unkeepable promise: no one can guarantee position zero on anything — featured snippets are chosen algorithmically and cannot be forced (§10.3) — let alone "on all of them in 90 days." Instead: build a smaller set of pages where the site has (or can create) genuine first-hand experience, aimed at winnable long-tail/experience-specific queries, and build authority over time (Ch 22–26).

Exercise 10.29

Risky for trust because a comparison written by someone who has never installed either option is built from rewritten spec sheets, not lived knowledge — it will miss the hidden costs, failure modes, and "in this situation choose that" judgments a buyer actually needs, and readers sense the hollowness. Risky for rankings because Google's reviews system and Helpful Content guidance explicitly reward evidence of first-hand experience (the "Experience" of E-E-A-T, Ch 5) and demote experience-free content, so the page competes poorly and ages badly. The honest fix: have (or closely interview) a technician who installs both, capture their real judgments, original photos, and specifics, and put a named, credentialed author on the page — turn the company's genuine experience into the content's moat.

Exercise 10.30 †

• "furnace filter size chart" → informational, quick-reference → table/chart format (a scannable sizing chart, eligible for a table snippet); likely winnable — low authority barrier, and a reference chart is broadly linkable. Consider adding a tiny "find your filter size" helper (interactive, §10.5).
• "why does my AC freeze up" → informational, diagnostic → diagnostic guide (causes → fixes → when to call a pro), PAA-structured; winnable as a long-tail experience-rich query where a real HVAC company's expertise is a moat. What the format decision does not settle: it doesn't write the pages, earn the links, or guarantee ranking — format is Gate 1; comprehensiveness, authority, and time decide Gate 2.

Exercise 10.31

(Guided — answers vary by site.) The deliverable is a five-row table in the style of Figure 10.3: each row a target query, its intent (Ch 3), and a one-line format decision, with at least one row marked skip and a reason (e.g., "'best [category]' — authority ceiling; owned by review publishers; cover inside experience-rich pages instead"). Fold it into the running Strategy File (Appendix C). Strong submissions read each SERP first and let the ranking formats drive the decision, rather than defaulting every query to "a blog post."

Exercise 11.1

Signals you control: descriptive filename (anode-rod-corrosion.jpg, not IMG_4821.jpg); alt text; the caption and surrounding text; structured data (ImageObject/Product/VideoObject); and the overall page context (what the page is about). The capability you cannot tune: Google's own machine vision — it analyzes the pixels directly (objects, text via OCR, products, landmarks). You can't optimize the vision model; you can only give it a clear, unambiguous subject to recognize and confirm it with words and markup.

Exercise 11.3

EXIF (Exchangeable Image File format) is metadata a camera embeds inside an image file. It really contains things like the camera model, exposure settings, a timestamp, and sometimes GPS coordinates. What it does not reliably do for SEO: boost rankings — there is no credible evidence Google uses EXIF GPS ("geotagging") as a local ranking factor, and stuffing keywords into EXIF does nothing. The one embedded-metadata standard Google documents reading is IPTC licensing metadata (for credits and the "Licensable" badge), which is a different thing.

Exercise 11.4 †

VideoObject is the Schema.org structured-data type that describes a video to search engines (its name, description, thumbnail, upload date, duration, and play URLs), making it eligible for video rich results. Video key moments are timestamped, clickable segments Google can show beneath a video result that jump the viewer to a specific point. Google populates key moments two ways: (1) automatic detection (it identifies moments itself, working especially well when a video has clear chapters/timestamps), or (2) explicit markup (the Clip or SeekToAction properties attached to your VideoObject).

Exercise 11.5

A thumbnail is the still preview image that represents a video. It is one of YouTube's biggest levers because it is the main thing a browsing viewer sees before deciding to click, so it drives click-through rate (CTR) — and CTR is a ranking/recommendation input on YouTube. A custom, high-contrast, legible thumbnail routinely outperforms an auto-generated frame grab, which is why creators invest heavily in thumbnails.

Exercise 11.7

An image sitemap is image information (the image URLs tied to each page) added to your XML sitemap. It helps with discovery — helping Google find images — not ranking. It is genuinely useful when images are loaded in ways the crawler struggles with, e.g., via JavaScript or CSS backgrounds rather than plain <img> tags, or for very large catalogs. It is usually unnecessary for a straightforward site whose images are ordinary <img> elements on crawlable pages, since Google already finds those by crawling the page.

Exercise 11.9 †

Alt text written well for a screen-reader user describes the image truthfully and concisely in context — and that is exactly the text Google needs to understand what the image is about for Google Images. The two goals converge because both want an accurate, natural-language description. The reverse fails at both: optimizing "for Google" by cramming keywords produces a string that (a) is gibberish read aloud to the blind user the attribute exists for — an accessibility failure — and (b) describes nothing and reads as a spam pattern to Google — so it doesn't even deliver the image-search benefit. Truthful description is the only move that serves both; there is no real trade-off to make.

Exercise 11.11

"Never lazy-load your LCP image" is a rule because Largest Contentful Paint (LCP) measures how quickly the largest piece of main content — very often the big above-the-fold hero image — paints. Lazy loading defers an image until it's needed; deferring the hero means the browser waits before even requesting the single most important pixel on the screen, directly delaying LCP. So: lazy-load images below the fold (a speed win); eager-load the top-of-page hero. (Full LCP treatment: Chapter 16.)

Exercise 11.13

Can do: VideoObject markup gives Google explicit, machine-readable facts about a video (what it is, how long, when posted, where the thumbnail is), making it eligible for video rich results — thumbnail, duration, upload date — and key moments make it eligible for clickable step links that enlarge and improve the result. Cannot promise: that Google will actually grant the rich result, show the key moments, or rank the video anywhere in particular. Rich results and rankings are Google's call; markup earns eligibility, never an outcome (we never promise rankings).

Exercise 11.15 †

Likely problem: the images aren't discoverable by the crawler. Loading images as CSS backgrounds via JavaScript means there are no plain <img> tags for Googlebot to find, so the images may never enter the image index — and an image that isn't in the index can't appear in Google Images. Two fixes from this chapter: (1) serve the important images as real <img> elements (with descriptive alt text) so they're crawlable, and/or (2) add an image sitemap listing the image URLs to aid discovery of images loaded via JS/CSS (§11.7). Fixing crawlability is the priority; the sitemap is a supplement.

Exercise 11.16 †

Two distinct problems. (1) The images are too heavy (3–4 MB), which slows the page and is very often the Largest Contentful Paint (LCP) problem — fix: convert to a modern format (WebP/AVIF), compress, and serve an appropriately sized image (responsive srcset), not a 4000px file in a 400px box. (2) The layout "jumps" as images load, which is a Cumulative Layout Shift (CLS) problem caused by images without reserved space — fix: set each image's width and height (or a CSS aspect-ratio) so the browser reserves the space before the image arrives. (Metrics and thresholds: Chapter 16.)

Exercise 11.17

Verify the video-indexing basics from §11.4: (1) Is the video the main content of a public, crawlable page? Since the 2023 change (Case Study 2), an incidental/sidebar video generally won't get a thumbnail. (2) Is there a proper thumbnail and a supported format with a stable URL? (3) Does the page describe the video in text (title, summary, ideally a transcript), and — to move from indexed to rich — is there VideoObject markup? Also worth checking: the Search Console Video indexing report for the specific reason Google gives (Chapter 27).

Exercise 11.19

Two plausible, chapter-based reasons: (1) The competitor's product images are in Google's image index and the retailer's aren't — e.g., the retailer's images are loaded via JS/CSS, blocked, or otherwise not crawlable, so Lens has nothing to match (checks: view source for real <img> tags, confirm images aren't blocked, consider an image sitemap). (2) The competitor's images are clearer and better-described, with accurate Product structured data, so Google's vision model matches them confidently while the retailer's are cluttered, multi-subject, or unlabeled (checks: single-subject well-lit product shots, accurate structured data — Chapter 18). You can't "target" a Lens query; you make your images eligible to be matched.

Exercise 11.21 †

(Guided — results vary by site.) The deliverable is a per-page tally plus a one-sentence worst-offender note. Example: "On the services page, 12 of 18 images have missing alt, 4 are alt='IMG_####', and 2 are usably descriptive; the worst offender is the hero (no alt), which I'll fix to alt='A Rivertown technician servicing a rooftop AC unit'." The point is to convert a vague "our images aren't optimized" into a concrete, prioritized fix list — and to notice that missing alt is worse than empty alt, and stuffed alt is worse than thin. Free tools: WAVE, Lighthouse accessibility audit, or View Page Source.

Exercise 11.23

(Guided.) The deliverable is a competitive one-line video brief grounded in what YouTube already rewards for the query. Example: for "how to relight a furnace pilot light," autocomplete surfaces "...won't stay lit," "...millivolt," "...after gas outage"; the top results are 3–6 minute how-tos with high-contrast thumbnails and chaptered steps. Brief: "A ~3-min, safety-first how-to led by a licensed technician, chaptered (Safety → Find pilot → Hold reset → Relight → When to call a pro), with a custom thumbnail showing the pilot assembly and bold text 'RELIGHT SAFELY.'" The method (read the top results as the answer key) mirrors Chapter 10's "read the format off the SERP," on YouTube.

Exercise 11.25 †

Biggest, most fixable line: "No video thumbnail" (18). A thumbnail is a basic eligibility requirement, and 18 videos lacking one is a large, mechanical fix (provide a proper poster/thumbnail image and, ideally, VideoObject with thumbnailUrl). Check first that each page actually specifies a thumbnail Google can fetch. The "not the main content" (9) line implies the post-2023 rule (Case Study 2): Google shows a video thumbnail mainly when the video is the page's main content — so those 9 are on pages where the video is incidental, and the honest fix is either to make the video central (if the page is truly about it) or to accept no thumbnail. The "unsupported format" (4) is a small, clear technical fix.

Exercise 11.27

Every claim is false. There is no lens-optimize meta tag; embedding keywords in EXIF does nothing for Lens (or rankings); and there is no keyword-based "secret" to visual search at all, because Lens matches pixels and facts, not keywords. Replace the whole thing with what actually helps images appear in visual search: publish high-quality, well-lit, single-subject images that are actually in Google's image index (crawlable <img> tags, not blocked; image sitemap if loaded via JS/CSS); back products with accurate Product structured data (Chapter 18); describe images truthfully (alt text, context); and be a generally trustworthy source. Clarity and accurate data, not tricks.

Exercise 11.28 †

Three responsible inclusions for a gas-safety how-to: (1) a prominent up-front safety warning — if you smell gas, leave immediately and call the gas company / emergency line; do not attempt this — repeated in the video and the description; (2) a licensed technician on camera, with their name and license noted in the description, demonstrating the manufacturer-recommended steps rather than improvised shortcuts; (3) a clear "when to stop and call a pro" boundary. This strengthens E-E-A-T (Chapter 5): a real, named, licensed professional demonstrating correct procedure is visible Experience and Expertise that text can't fake, and the transparent safety framing builds Trust. What the video should not do: give unqualified, dangerous shortcuts, omit the warnings, imply the viewer should tackle a gas leak themselves, or present an unlicensed person as an authority. (The YMYL-adjacent framing is Chapter 35's.)

Exercise 11.29

Accessibility objection: "Blue Trail Jacket best price Denver" is not a description — a screen-reader user learns nothing about what the image shows (color, cut, what's visible), and "best price" + city are meaningless noise read aloud. SEO objection: it's templated, repetitive, near-stuffed text that describes nothing and can read as a spam pattern, wasting the real opportunity (an accurate visual description that helps the image rank in Google Images and match in Lens). Better automated approach: generate a truthful base description from real product attributes already in the catalog — e.g., alt="Blue insulated hooded trail jacket, front view" from color/type/feature fields — and keep commercial phrases ("best price," city) in the page copy, where they belong, not in the alt text.

Exercise 11.30 †

(Guided model answer.) Two images for the water-heater guide: 1. Filename: corroded-anode-rod-water-heater.jpg · Alt: A water-heater anode rod heavily corroded and flaking after years of use, held beside the tank. — Helps readers (shows what a failing anode rod looks like, aiding self-diagnosis), Google Images (a clear, described image eligible to rank for "corroded anode rod"), and Google Lens (a customer who photographs their own corroded rod can be matched to this clearly-labeled example). 2. Filename: water-heater-drain-valve-leaking.jpg · Alt: A leaking drain valve at the base of a residential water heater, with water pooling below. — Helps readers (identifies a common leak point), Google Images (ranks for the part/problem), and Lens (matches a photographed leaking valve, exactly the §11.6 scenario). Each image is a single, clear subject, truthfully described — serving the accessibility user first and the two search surfaces as a by-product.

Exercise 11.31

(Guided model answer.) Title: "How to Relight a Furnace Pilot Light — Safely, Step by Step." First two description lines: "A licensed Rivertown technician shows the safe, manufacturer-recommended way to relight a standing pilot light. ⚠️ If you smell gas, leave now and call your gas company — don't attempt this." Chapters: 0:00 Safety first (if you smell gas, stop) · 0:35 Find the pilot assembly & gas control · 1:20 Turn to OFF and wait · 2:05 Hold RESET and relight · 2:50 When to stop and call a pro. Thumbnail concept: a close-up of the pilot assembly with a gloved technician's hand and bold, legible text "RELIGHT SAFELY." Justification (§11.5): the title answers the real search and leads with value; the first description lines carry the hook and the safety warning where they'll be seen; timestamped chapters improve viewing and feed key moments (§11.4); the custom, high-contrast thumbnail drives CTR; and the on-camera licensed technician supplies E-E-A-T.

Exercise 12.1

Content decay is the gradual loss of a page's search traffic after it has peaked — a slow leak, not a sudden crash, and usually not a penalty. Three distinct causes: (1) competitors improved — someone published a better answer and you stood still (ranking is a relative contest, so you can fall without changing a word); (2) information went stale — prices, dates, features, and examples aged out, so the page genuinely got worse; (3) SERP erosion — an AI Overview, a featured snippet, or more ads took clicks off the top, so the same position now yields fewer clicks. The one that is not the page's fault is (3): the content didn't get worse, the results page changed around it. (Others: intent shift, a core/Helpful-Content reassessment, technical decay; and seasonality, which only looks like decay.)

Exercise 12.3

The four audit axes are traffic (GA4 sessions / GSC clicks), rankings (GSC position and impressions), conversions (GA4 — does it drive calls, forms, sales?), and quality (a manual read: accurate, complete, unique, on-intent?). The two additional columns that save you from expensive mistakes are backlinks (does any other site link to it? — earned equity you must not throw away) and indexation status (is it even in the index, or "crawled – currently not indexed"?). The point of the extra two: a page with no traffic but real backlinks is not a delete candidate, and a page with no impressions may simply never have been indexed.

Exercise 12.4 †

The four decisions, in order: keep (it performs and is accurate — monitor, light touch-ups), update (it has equity or demand but has decayed or was never fully realized — genuinely improve it: historical optimization), merge (a better page on your own site covers the same intent — consolidate the useful parts and 301-redirect this URL into it), and delete (no value, no links, no strategic role, unsalvageable — remove it, redirecting to a relevant target or letting it 404/410). The one-line test that routes a page to merge rather than delete: is there a better page on your own site covering the same intent? If yes, merge (fold the value in and redirect, preserving it). If no, and there's nothing worth saving, delete.

Exercise 12.5

Historical optimization is systematically improving and re-publishing existing content instead of always creating new content — updating your old pages to reclaim or grow their traffic. Two assets an already-published page has that a blank page does not (any two): it is already indexed (it cleared the quality gate); it has age and history (Google has seen it perform and it carries whatever trust it accrued); it may already rank (often on page two, a few positions from real traffic); and it holds whatever links and internal signals it earned. A new page starts all of that at zero — which is why updating an equity-bearing page is usually faster, cheaper, and higher-return than writing a new one on the same topic.

Exercise 12.7

Freshness is the degree to which Google favors more recent content for a given query — a real capability, often discussed as "Query Deserves Freshness" (QDF). Query-dependent means it applies unevenly across queries: recency is part of relevance for some searches and irrelevant for others, so freshness is a strong signal for the first group and weak-to-absent for the second. A query where it helps a lot: time-sensitive ones like "power outage [city] today" or "best space heaters 2026." A query where it barely applies: evergreen ones like "how to relight a furnace pilot light" or "what is a mortgage," where a great older page routinely beats a fresh thin one. The mistake is treating freshness as a universal factor; it isn't.

Exercise 12.9 †

The honest mechanism by which pruning a bloated site raises total traffic has three parts: (1) the site-wide quality signal rises — Google assesses quality partly at the site level (the Panda lesson; the Helpful Content guidance says removing unhelpful content can help the rest), so removing a mass of thin pages stops them averaging down the good ones; (2) attention concentrates — crawling, internal links, and editorial effort focus on fewer pages, so survivors gain internal link equity and care; (3) cannibalization resolves — the overlapping pages you merged stop competing with each other, so one strong page beats several weak ones. No gain condition: a lean site with little dead weight — there's nothing to remove that was dragging you down. Loses-traffic condition: deleting pages that actually had traffic or backlinks (throwing away equity), or redirecting removed pages to an irrelevant target like the homepage (a soft 404 that transfers nothing). Pruning is a consequence of removing genuine dead weight, never a reward for deleting.

Exercise 12.11

Historical optimization genuinely improves the page — new information, better coverage, current examples, a re-matched intent, on-page fixes — so the content meaningfully changes. Freshness theater is changing the "last updated" date (or making a trivial edit) without changing the substance. One earns a benefit because Google evaluates whether the content changed, not whether the timestamp did; on a QDF-sensitive query a real improvement can also earn a freshness bump as a by-product. The other earns nothing because there's no substance behind it — and it can actively hurt: displaying "Updated 2026" on content you didn't revise is deceptive to users and erodes the trust that genuinely matters (the T in E-E-A-T). One is the work; the other is the costume.

Exercise 12.13

Using round, explicitly-illustrative CTRs (the book refuses fake-precise numbers): at position 9, CTR ≈ 2%; at position 4, CTR ≈ 9%. Volume = 1,500 monthly searches. Extra monthly visits ≈ 1,500 × (0.09 − 0.02) = 1,500 × 0.07 = 105 additional visits per month. This is an illustration, not a promise, for three reasons: the CTRs are round stand-ins (real CTR varies enormously by query and by how many SERP features crowd the page); reaching position 4 is an if, not a guarantee (we never promise rankings — it depends on competitors we don't control); and volume itself fluctuates. The shape is the transferable point: a five-position gain on a real-volume query is a meaningful traffic swing from updating one page you already own — which is why striking-distance updates are where the leverage is.

Exercise 12.15 †

Check first: Search Console — did the average position hold while CTR fell? A flagship guide steady at position 2 with clicks down ~30% year-over-year is the classic signature of SERP erosion, not a ranking loss: the page still ranks where it did, but the results page changed around it — most likely an AI Overview or a featured snippet now answers the question above it, or more ads/features pushed it down the screen, so the same position yields fewer clicks. If that's what the data shows, the rewrite is wasted effort, because the page was never the problem — you'd be pouring work into content that already ranks #2. The strategic responses are different: deepen the page so it offers something the AI summary can't (originality, first-hand experience, tools), pursue the queries less affected by the feature, and — above all — diversify traffic (email, direct, brand) so a SERP-layout change can't gut you (Chapters 6, 36). Only if position actually fell would a content/competitive response be the right call.

Exercise 12.16 †

The problem is keyword cannibalization: two of your own pages are targeting the same query and intent, Google can't confidently choose between them, so it alternates and dilutes — splitting internal links and relevance signals across both — and neither reaches page one. The preferred fix is to merge/consolidate: fold the useful material from both into a single comprehensive page and 301-redirect the weaker URL into the survivor, so the combined relevance and link equity concentrate on one page that can actually own the query. What you do to the "losing" URL: don't just delete it (you'd lose whatever equity and internal links it has) and don't leave it live (the competition continues) — 301-redirect it to the surviving page, and re-point any internal links that aimed at it to the survivor. (If, on inspection, the two pages actually serve different intents, the alternative is to differentiate them rather than merge — but two URLs trading places in the low teens for one query is the merge signature.)

Exercise 12.17

What went wrong: this is freshness theater. Changing the published date without changing the content does nothing, because Google evaluates whether the content meaningfully changed, not the timestamp — there is no evidence a bare date change lifts rankings, and freshness is query-dependent anyway (most of 200 old posts are probably evergreen, where freshness barely applies). Worse, it produced a real harm: readers noticed the "updated" articles were obviously unchanged, which is deceptive and erodes trust (E-E-A-T). What real historical optimization would have required: actually improving the pages worth improving — refreshing stale facts and examples, adding the coverage and follow-up questions rivals answer (comprehensiveness, Chapter 9), re-matching the current intent, fixing titles and internal links — prioritized by the audit (start with striking-distance pages), not applied blindly to all 200. The accurate date then follows honestly from real changes; it is a by-product, never the goal.

Exercise 12.19

It's a diagnostic trap because the furnace page's traffic is seasonal, not decaying. Demand for furnace repair genuinely falls in spring and rises in autumn, so a spring "drop" is the normal cycle, not a page losing its standing. Deleting it in spring would throw away an autumn earner — a self-inflicted wound. The comparison that settles it: look at the page year-over-year (this spring vs. last spring), not month-over-month (this spring vs. last winter). If the page is flat or up year-over-year, it's healthy and seasonal; only a genuine year-over-year decline is decay worth acting on. Always rule out seasonality before diagnosing decay.

Exercise 12.21 †

(Guided — results vary by site.) The deliverable is your five biggest decliners with a ranking-loss vs. SERP-erosion label on each, and a one-sentence verdict on which dominates. Example: "Comparing the last 6 months to the prior 6 in Search Console → Performance, my biggest decliners are five buying guides. Four of them show average position roughly steady but CTR down — SERP erosion (a featured snippet and, on two, an AI Overview now sit above them); one shows position genuinely down from 4 to 11 — a real ranking loss where a competitor overtook me. So most of my decline is SERP erosion, which means rewriting won't fix it — I should deepen those pages and diversify traffic, and reserve a content/competitive push for the one page that actually lost rank." The method is the point: separate the two failure modes with position-vs-CTR before deciding on any fix.

Exercise 12.23 †

(Guided model answer; specifics vary.) Filtering Search Console to positions ~5–20 with real impressions, pick one page — say a guide sitting at position 8 for a query with ~1,200 monthly searches. Three specific improvements: (1) rewrite the title tag to match the query directly and lift CTR (Chapter 9); (2) add the coverage rivals have — the two or three follow-up questions the page currently ignores (comprehensiveness); (3) add three internal links from stronger related pages to pass authority to it (Chapter 15). Illustrative traffic swing if it reached the top of page one (position ~3): with round CTRs of ~2% at position 8 and ~10% at position 3, 1,200 × (0.10 − 0.02) = 96 extra visits a month — from updating a page you already own, labeled an illustration (not a promise; reaching position 3 depends on competitors).

Exercise 12.25 †

The fit is UPDATE (historical optimization). The evidence across the axes: it has steady real traffic (260 sessions/yr) and — crucially — it converts (9 booking-form starts), it ranks well (position 6 for a 1,000-search query, so it's in striking distance of the top), it holds genuine local backlinks (equity worth building on), and it's indexed. The only weak axis is quality/freshness: it's three years old and missing the "questions to ask" and "licensing" angles rivals cover. So you don't delete a converting, linked, ranking page — you improve it. Specific work to queue: add the missing sections (questions to ask a contractor; how to verify licensing/insurance), refresh any dated details, tighten the title/meta for CTR (Chapter 9), and add internal links from related service and blog pages to push it from position 6 toward the top. One thing you would NOT do: delete it or redirect it away — it converts and has links; nor would you merely change its date without doing the real update (freshness theater).

Exercise 12.27

Every part of the claim is false or misleading. "Google rewards fresh content" is only query-dependent — strong for time-sensitive queries, weak-to-absent for the large universe of evergreen ones, so "keep everything fresh" is wrong as a blanket rule. "Update every post's date monthly" is freshness theater: Google reads changed content, not the timestamp, so a bare date change earns nothing — and stamping "updated" on unchanged content is deceptive and erodes trust (E-E-A-T). And "you'll keep your rankings" misdiagnoses decay, which is usually competitors, staleness, or SERP erosion, none of which a date fixes. Replace it with: freshness is earned by changed substance, and only matters where the query rewards recency; for evergreen pages, "keeping it fresh" really means keeping it accurate and best-in-class — you revisit a page because the information changed or a rival got more complete, not to chase a date. Do real historical optimization on the pages the audit flags; ignore the calendar.

Exercise 12.28 †

Rebuttal: "more indexed pages is always better" has no basis — quality per page and the site's overall helpfulness are what matter, not the raw URL count. The Panda update (2011) established, and every core update since has reinforced, that Google assesses quality partly site-wide: a mass of thin, low-value pages can suppress the rankings of a site's good pages. So a thin page that ranks for nothing, converts nothing, and has no links is not a silent asset earning credit for existing — it's neutral clutter at best and, since the Helpful Content system, part of a pattern that can drag down your good work. "Never remove anything" also ignores cannibalization (overlapping pages competing with each other). The correct posture: removing genuine dead weight — via a real four-axis audit, preserving pages with traffic/links/conversions, and redirecting to relevant targets — is a legitimate, Google-endorsed remedy that loses nothing of value. (Both extremes are wrong: "delete for a boost" is a hack that fails, and "never delete" ignores that thin pages have a cost. The truth is the scalpel in between.)

Exercise 12.29

Trust/E-E-A-T objection: displaying "Last updated: 2026" on 500 articles that were not revised is a factual misrepresentation to the reader. It manufactures a false signal of currency, and when readers (or Google) notice the content is plainly stale behind a fresh date, it damages the site's Trustworthiness — the center of E-E-A-T (Chapter 5) and the hardest thing to rebuild. It also does nothing for rankings, since Google evaluates changed content, not the stamp. Honest alternative: actually audit and update the articles that warrant it (historical optimization), and let each accurate date follow from real changes; for the rest, either leave the true original/updated date or show a "reviewed" date only if a genuine review occurred. The one situation where updating the date IS correct: when you have genuinely updated the content — then the new date is true, useful to readers, and a legitimate by-product (and, on QDF-sensitive queries, may even help).

Exercise 12.30 †

Extending Rivertown's MERGE verdict on the five "get your AC ready for summer" posts (published across five different years): the consolidated page should be one strong evergreen guide — "Summer AC Maintenance: A Homeowner's Checklist" — covering everything the five thin posts scattered: changing the filter, clearing the condenser unit, checking the thermostat, when to schedule a professional tune-up, and the signs that mean "call Rivertown now." Which URL survives: keep the single best-performing existing URL (most traffic/links) as the canonical home, or mint one clean evergreen URL and redirect all five into it — pick the one with the most equity to inherit. The other four URLs: 301-redirect them into the survivor (they're near-duplicates, so the redirect is to a genuinely relevant target — value transfers), and remove them from the sitemap. Internal links to add: point the surviving guide at the AC-repair service page and the relevant location pages, and add links from those pages back to the guide. What this fixes: it removes thin, duplicative content and resolves the keyword cannibalization (§12.5) — five posts were competing for the same "summer AC prep" intent and undercutting each other; now one page can own it.

Exercise 12.31

Historical-optimization to-do list for "Signs your water heater is failing" (verdict: UPDATE — good bones, decayed): three content changes — (1) replace the 2019 price references with current, clearly-dated ranges (or remove specific prices and describe cost drivers instead); (2) remove the dead rebate-program link and, if a current program exists, link the live one; (3) add the follow-up coverage rivals have — how to tell "repair vs. replace," and the safety signs that mean "shut it off and call a pro." One on-page change (Chapter 9): rewrite the title tag to match the actual query and improve CTR (e.g., from a vague label to "6 Signs Your Water Heater Is Failing — and What to Do"). Two internal links to add: one to Rivertown's water-heater replacement service page, and one to the water-heater guide (the page stuck at #11) — passing authority and giving readers a next step. Honest limits: this update can make the page more complete, current, and better linked, improving its chances of ranking and converting — but it cannot promise a ranking (that's Google's call, and depends on competitors), and it won't overcome a far stronger competitor by itself; if the page still lags after a genuine update, the next levers are authority and internal linking (Chapters 15, 22), not another rewrite.

Exercise 13.1

AI-generated content is content (text, images, code) produced by a generative model — a description of how it was made, carrying no verdict on quality. Content at scale is content produced in large volumes — a neutral fact about quantity. Scaled content abuse is Google's spam policy against generating many pages primarily to manipulate rankings and not help users, with no value added, regardless of who or what produced them. The first two are neutral because both a legitimate large publisher and a spam farm use AI and produce at scale; what makes the third a violation is the combination of scale with absence of value and intent to manipulate. Method and volume are neutral; manipulation-without-value is the offense.

Exercise 13.2 †

Google's position (paraphrasing the epigraph): it rewards high-quality content however it is produced, appropriate use of AI is not against its guidelines, and using automation to generate content primarily to manipulate rankings is a spam violation. Who = is there a real, accountable author/organization behind it? How = how was it made (including, where it helps the reader, whether AI/automation was involved)? Why = was it created to genuinely help people, or mainly to win search clicks? The tell is Why: content made to help people can use AI and be fine; content made to manipulate is a problem no matter how it was produced. Intent, not method, is the dividing line.

Exercise 13.3

Information gain is the additional, original value a piece of content adds beyond what already exists on the web. A large language model is structurally weak at it because of what the model is: it is trained on the existing web and generates the statistically likely continuation of a prompt — a remix of what has already been written. It cannot run an experiment, gather new data, interview a source, form an opinion by doing the work, or report a fact the web does not already contain. So by construction it tends toward the consensus, which is exactly the content with the least information gain.

Exercise 13.5

An honest rewrite: "AI-generated content is not against Google's guidelines — Google rewards quality however content is produced. What violates the guidelines is scaled content abuse: producing content, by any method, primarily to manipulate rankings rather than to help users. Use AI as a tool within a process that verifies accuracy and adds genuine value, and there is no penalty for the method." (The correction removes the false premise that the tool is the violation and names the actual line, which is intent-and-value, not authorship.)

Exercise 13.6 †

Content at scale (legitimate): a reference site publishes 5,000 genuinely useful, distinct pages — each answering a real question with accurate, original, or well-sourced information a reader wants. Large volume, real value; entirely fine. Scaled content abuse: a site generates 5,000 thin pages by prompting a model against a scraped keyword list, each restating what already ranks, no original value, published to catch clicks. Same 5,000 pages — the difference is not the count and not the tool; it is that the first adds value for real users and the second is volume manufactured to manipulate rankings with nothing added. Scale is neutral; what you fill it with is the verdict.

Exercise 13.7

It means AI did not change the goal of content (be genuinely useful to a real person and make it legible to Google) — it lowered the cost of failing at that goal by making thin, generic, unoriginal content nearly free to mass-produce. The game is identical to Chapter 1's: help each stage of the pipeline work for content that deserves to rank, not trick the algorithm. What changed is that the temptation to do it badly (scale over substance) got cheaper and more tempting — which is theme one exactly: SEO is still not a trick, and the tool that makes tricks cheaper does not make them work. The durable path is unchanged; only the size of the spam pile grew.

Exercise 13.9

Because Google does not rank by authorship method (§13.1) — it evaluates the result (helpfulness, originality, accuracy, trust), which is orthogonal to "was a model involved." A perfect detector would answer a question no one who matters is asking. If your content is genuinely helpful, original, and accurate, being identified as AI-assisted changes nothing about how it ranks or whether it deserves to. If it is thin and generic, hiding the tool would not save it. So the detector — even a flawless one — is aimed at the wrong variable; the only work that moves rankings is making the content actually good, which you would do identically whether or not detection existed.

Exercise 13.10 †

The logic: value at the margin depends on scarcity. Before generative AI, competent, consensus content was relatively scarce and therefore had differentiating value — producing it well was an achievement. AI made that exact category abundant and nearly free: if a model can write your article, so can a thousand competitors' models, so generic content no longer distinguishes anyone. What remains scarce is what AI cannot produce — first-hand experience, original data, genuine expertise, accountable trust — so the differentiating value migrates entirely there. The conclusion a creator should draw: stop competing on the abundant thing (generic coverage) and invest in the scarce thing (experience, originality, real authority). The moat is not "write more"; it is "know and have done what the model hasn't."

Exercise 13.11

The policy violated is scaled content abuse: many pages generated primarily to manipulate rankings, with no value added — the fact that a model produced them is incidental. It was not "penalized for using AI"; a human-written version of the same 800 keyword-chasing thin pages would meet the same fate (as content farms did under Panda, Ch 6). The collapse came via a core update's site-wide quality reassessment, which is why it lagged the publishing by months (Ch 6). Is there a fix? Not one that preserves the model — the site is the problem; it has no genuine value to make legible, so pruning cannot save it. The only real path is to build something with actual value (real expertise/experience), which is a different site, not a recovery.

Exercise 13.12 †

Three things only a licensed technician could add, each mapping to an E-E-A-T component: 1. Specific diagnostic detail from experience — e.g., "nine times out of ten on this furnace model it's the flame sensor; here's the sooted-up look it has when we pull it" — the concrete failure modes and tells a practitioner knows. Experience (first-hand). 2. Accurate, current technical specifics — correct sequence, the actual safety cutoffs, when a code or a permit applies — verified against real knowledge, not the model's plausible guess. Expertise (and it catches hallucinations). 3. A clear, responsible safety boundary — exactly which steps a homeowner can safely try and which require a licensed pro (gas is involved), stated by a named, licensed person. Trustworthiness (accountability + safety), which for gas work brushes YMYL. The original draft has none of these — it is generic, hedged, and experience-free, i.e., zero information gain.

Exercise 13.13

No — it does not prove quality is pointless. The honest, two-sided reading: (1) Google approximates quality with signals, and approximations have false negatives, so a genuinely good site can be caught unfairly — this is real and documented. (2) That fact does not rescue scaled AI spam (the spam site still deserved demotion) and does not mean "be good" is a bad strategy — it remains the only strategy with a future. What it proves is narrower and important: quality is necessary but not sufficient; you are one entrant in a contest on a platform you do not control. The correct response is not to abandon quality but to also diversify traffic (email, brand, repeat customers) so a false negative is survivable while you do the slow, correct recovery (Ch 6, Ch 36).

Exercise 13.15 †

(Guided — results vary.) The deliverable is one interpretive sentence. The expected observation: the detectors disagree with each other and at least one flags your genuinely human writing as substantially "AI," because they infer from statistical properties (predictability, sentence rhythm) that clear, edited human prose also has. Example sentence: "Two detectors rated my hand-written page 20% and 82% 'AI' — the disagreement and the false flag show these tools estimate rather than know, so their verdict is close to noise and must never be used to judge a writer's work (or to decide what to publish)." The point is to experience the unreliability, not to trust a number.

Exercise 13.17

(Guided.) The deliverable is the gap: what an AI Overview (or the top result) covers, and the follow-up a searcher still has that the summary skips. Example: for "how long does a furnace last," the AI Overview gives the generic "15–20 years" consensus; the unanswered follow-up is "how do I tell if mine specifically is near the end, and is repair or replace cheaper at year 14?" — which requires experience, local pricing, and judgment a summary can't supply. That gap is your information-gain opportunity: the content an AI Overview cannot fully replace is the content with what the model lacks (first-hand assessment, specifics, the real "it depends, and here's how to tell").

Exercise 13.18 †

Site X (3,500 templated, author-less, value-free pages, down ~90%): the demotion is the system working as designed — textbook scaled content abuse (scale + no value + manipulation). The sensible move is that there is no move that saves the model; the site has no genuine value to make legible, so it should be rebuilt around something real or abandoned. Site Y (400 genuine expert pages plus 150 thin AI explainers, down ~45%): the harder case — real value diluted by thin filler dragging down the site-wide quality signal (the content-audit lesson, Ch 12). The move: prune the 150 thin posts, deepen and foreground the genuine expert content, make experience legible (§13.6), and wait for reassessment — while diversifying traffic. Prune, don't pile on.

Exercise 13.19

(Guided — additions are illustrative and should be labeled.) A revised opening injects experience and information gain, e.g.: "Relighting a gas water-heater pilot is usually a five-minute job — but before you touch anything, if you smell gas at all, stop and call the gas company; that smell is the one situation where this is not a DIY task. [First-hand:] On the older tank models we service most, the reset button has to be held a full 60 seconds after the flame catches, not the 10 seconds most people give it — let go early and it drops out every time, which is the single most common reason a homeowner calls us thinking the unit is broken when it isn't. Here's exactly what the control valve looks like…" The additions supply a real safety boundary, a specific practitioner detail (the 60-second hold) absent from generic guides, and the tell that saves a service call — none of which a model could know, all of which is information gain. Label invented specifics as illustrative.

Exercise 13.21 †

Two false assumptions bundled in "an AI detector verifies content is safe from Google penalties": 1. That the detector is accurate. It is not — false positives flag human writing (notably non-native English), false negatives clear edited AI, the tools disagree, and OpenAI shut down its own for low accuracy. Its verdict is close to noise, so it "verifies" nothing. Correction: detectors cannot reliably tell AI from human, so they cannot certify anything. 2. That Google penalizes based on authorship (so a detector predicts Google's judgment). Google ranks quality, not authorship method, and does not run these detectors as a ranking step. Correction: the thing you'd be testing for is not the thing Google acts on — so even a perfect detector would not tell you whether the content is "safe." Delete the step; verify accuracy and originality instead.

Exercise 13.23

Guardrails violated: (1) Fabricated authority / fake expert byline — a fabricated "Dr." is a lie about who stands behind the content, the counterfeit of Expertise and Trust (Ch 5, §13.7). (2) YMYL harm — unqualified medical advice can hurt people; the book's rule is to teach how credible sites demonstrate genuine expertise and to never model making unqualified content appear authoritative (Ch 5, Ch 35, §13.7 guardrail). (3) Accountability failure — publishing unverified model output as authoritative medical guidance means owning false claims presented to vulnerable readers (§13.7). (4) Likely scaled content abuse / trust violation if done at volume (§13.1). This is the single most irresponsible pattern in the chapter: the correct action is not to publish medical advice you are not qualified to give, AI draft or not.

Exercise 13.24 †

It is your error the instant you publish — you own every published word, including the ones a model drafted and you failed to verify. The fabricated statistic is no longer "the model's hallucination"; it is your false claim, told under your name to a reader who trusted you. The chapter says your responsibility before publishing was the verification step (§13.5's expert review) — checking every factual claim and killing every hallucination — which is the ethical core of the whole workflow, not an optional nicety. "The AI wrote it" is not a defense; if you were not willing to stand behind the claim, you were not willing to publish it.

Exercise 13.25

The "commons" is the shared web/search ecosystem your business depends on to reach customers. Every thin, unoriginal, machine-spewed page added to it makes search worse for everyone — noisier, harder to filter, less trustworthy — which is precisely why Google built the systems (scaled-content-abuse policy, Helpful Content) to fight it. Mass-publishing thin AI content is therefore defection: you take a small private gain (some clicks) while degrading the shared resource that your own visibility relies on — and if everyone defects, search becomes unusable and the channel dies for all of you, yourself included. The professional stance is cooperation: publish less and better, add real value or don't add to the pile.

Exercise 13.26 †

(Model answer — a step-1 brief.) "Topic: 'why is my AC freezing up' — informational intent, homeowner in summer, likely panicked and hot. Angle: the honest 'here's what's actually happening and what you can safely do now vs. what needs a tech.' Real experience only a technician can supply (capture as voice notes): the two causes we see most on real calls in this metro (a dirty filter/airflow starvation vs. low refrigerant), how to tell them apart from the outside without tools, the specific mistake homeowners make that turns a $0 fix into a compressor replacement (running it while frozen), roughly how long to let it thaw, and the exact symptom that means 'stop and call us tonight.' Author: [named lead HVAC technician], licensed, with the license number." The brief front-loads the information gain and experience the model cannot generate; the model's job (step 2) is only to turn this into a clean first draft.

Exercise 13.27

Because Rivertown's blog problem was never "too few pages" — it was a low overall quality signal dragged down by thin, neglected content, which the Ch 12 audit fixed by pruning and improving. Generating 300 new AI posts adds 300 more thin, generic, experience-free pages — increasing the dead weight the audit just removed, and (if aimed at catching keywords with no value added) drifting toward scaled content abuse under the family name. It rebuilds the exact problem, faster and cheaper. The content-audit logic is "less, but better"; "generate 300 more" is "more, but worse" — the precise opposite move, made tempting only because AI made the wrong move cheap.

Exercise 13.29 †

On-page elements that make the technician's review visible (the E-E-A-T legibility step), each with what it demonstrates: - A named, licensed author byline (real technician's name + role) — Expertise/Trust; something a reader and Google's signals can attach to a track record. - A "reviewed by [named licensed technician], [date]" line — Trust; shows genuine verification happened and when (currency). - The license number / certification (where the state board publishes it) — Expertise; verifiable, not asserted. - Original photos of real Rivertown crews/jobs, not stock — Experience; visual proof of first-hand work. - Specific first-hand detail in the copy ("on the units we service most…") — Experience/information gain; the thing a model and an AI Overview can't produce. - A short "how we made this" transparency note where it helps the reader (Who/How/Why) — Trust. Together these turn Rivertown's genuine, hidden authority into visible, machine-legible E-E-A-T — the whole point of the workflow.

Exercise 14.1

robots.txt controls crawling (which URLs a compliant crawler may fetch); it does not control indexing (whether a page appears in search results). Completed sentence: "A URL blocked by robots.txt can still be indexed — as a bare, snippet-less listing — if other pages link to it."

Exercise 14.3 †

A 301 (Moved Permanently) tells Google the URL has moved for good: consolidate the old URL's ranking signals onto the new one and eventually replace the old URL in the index with the new. A 302 (Found / temporary) says the move is temporary: keep the original URL indexed because it's coming back. Using a 302 when you mean a 301 is a mistake because it tells Google to keep the old URL — so the signal consolidation and index swap you wanted are slowed or don't happen. (Many servers/CMSs default to 302, so this misconfiguration is common; return the code you actually mean.)

Exercise 14.5

A 404 (Not Found) is the correct, honest response for a URL where no page exists — normal and harmless. A soft 404 is a page that returns a 200 OK status while actually showing "not found" or effectively empty content — it lies to Google that a real page exists. The soft 404 is the genuine defect: it wastes crawl, clutters the index, and confuses Google's understanding of the site; fix it by returning the honest code (404/410) or by putting real content on the page.

Exercise 14.6 †

Index bloat is having many low-value, thin, or duplicate URLs sitting in Google's index, so your indexed footprint is far larger and junkier than your set of genuinely valuable pages. Three common sources: (1) tracking/parameter URLs (?utm=, sort/filter params); (2) thin auto-generated archives (tag, category, author, date, attachment pages); (3) faceted-navigation combinations on e-commerce sites. A smaller, cleaner index is usually better because a mass of thin pages is itself a negative quality signal, and on large sites the junk wastes crawl budget that should go to real pages — a tight index of pages that all deserve to be there beats a bloated one.

Exercise 14.7

For a staging site that must never appear in search, a site-wide noindex is safer than robots.txt — but the truly safe answer is password protection (authentication), so the public can't reach it at all. The specific risk of the robots.txt Disallow: / approach is the classic catastrophe: if that file is ever copied to production (which happens on launch day), it blocks the entire live site from crawling. And a subtle second risk — a robots.txt-blocked staging URL can still be indexed from any stray link, as a bare listing, because blocking the crawl doesn't de-index. Best practice: put staging behind a login; if you also use noindex, keep it crawlable so Google can read it.

Exercise 14.8 †

For the owner: "Think of robots.txt as a sign on the door that says don't come in and look around. But to obey your other sign — the one on the page that says don't list me in search — Google first has to come in and read it. If you block the door, Google never sees the 'don't list me' note, so the page can stay in Google as a blank link. The fix is the opposite of what feels natural: let Google in to read the page, and put a noindex on the page itself." The one-sentence rule: to remove a page from Google, allow the crawl and add a noindex — never block it in robots.txt.

Exercise 14.9

Consolidate all six URLs onto one clean canonical URL, and use the right tool for each cause: (1) pick one host and protocol — serve https and one of www/non-www, and 301-redirect the other host/protocol variants to it (these are true "this URL should be the one" moves); (2) for the two tracking-parameter versions (which you want to keep clickable in campaigns), add a canonical tag on every variant pointing at the clean URL, so Google consolidates signals without you having to kill the links; (3) make the clean URL self-referencing canonical; (4) list only the clean URL in your sitemap and point internal links at it, so every signal agrees. Result: one indexed URL, all signals pooled.

Exercise 14.11 †

Return 503 (Service Unavailable) during the maintenance window, ideally with a Retry-After header telling Google when to come back. If the site instead returns 200 OK with a "we'll be back soon" page, you tell Google that placeholder is your real content — Google may crawl and even index the maintenance page in place of your real pages, and treat the outage as normal content rather than temporary downtime. The 503 says "temporarily down, don't hold it against me, come back later," which is exactly what you want.

Exercise 14.13 †

"Indexed, though blocked by robots.txt" means: Google discovered the URL (something links to it), so it put the URL in the index — but because robots.txt blocks the crawl, Google can't fetch the page to see its content or any noindex on it. So the page is in the index as a bare, uninformative listing, and blocking prevented the very thing that would remove it. To actually remove it: (1) un-block the URL in robots.txt so Google can crawl it; (2) add a noindex to the page (meta robots or X-Robots-Tag); (3) wait for Google to re-crawl, read the noindex, and drop it; (4) optionally, once it's out, re-block for crawl efficiency. Block-then-noindex, in that order, is the trap; un-block-then-noindex is the fix.

Exercise 14.15

The 250 "Crawled – currently not indexed" posts are an indexing-stage quality/priority verdict: Google fetched them and judged them not worth keeping (usually thin, similar, or low-value). Link building is a ranking-stage move, and you cannot rank — or, here, even get indexed — by pointing links at pages Google has already decided are thin. The wrong first move. The right move is a content audit (Chapter 12): improve and consolidate the genuinely useful posts (merge overlapping ones, deepen thin ones), and prune or noindex the rest, so the blog's overall quality rises and the survivors earn indexing on the merits.

Exercise 14.16 †

The condition is index bloat (~9,000 indexed vs. ~300 real). The two most likely URL types inflating it: (1) parameter/tracking URLs (sort, filter, session, ?utm=) and (2) thin auto-generated archives (tag/category/author/date/attachment pages). The two tools to fix it: canonical tags (to consolidate parameter duplicates onto clean URLs) and noindex (to drop the thin archives from the index — applied while keeping them crawlable so Google can read it). Confirm progress in the Page indexing report as the indexed count falls toward ~300. (Do not simply Disallow them in robots.txt, or already-indexed junk freezes in place.)

Exercise 14.17

No — a 404 is the wrong response for these three, precisely because they are linked from elsewhere (the Google Business Profile, and likely other sites). A 404 throws away the traffic those links send and the ranking signals they carry. The right response is a 301 redirect from each old URL to its best live equivalent (the new location of that content, or the closest relevant page), so both visitors and link signals are preserved. The general rule from §14.5: let genuinely valueless dead pages 404, but 301-redirect valuable dead URLs — especially any that people or other sites still link to.

Exercise 14.19 †

(Guided — answers vary by site.) The deliverable is a short risk read of your live robots.txt. Flag, in order of danger: a Disallow: / on a production site (blocks everything — emergency); a blocked resource folder like /wp-content/, /assets/, or a JavaScript/CSS path (can stop Google rendering the page properly); any real content section disallowed by mistake; and a missing Sitemap: line (minor). If none of those appear and the file only blocks admin/cart/search paths, write: "robots.txt is doing its job — blocking non-content paths, nothing important." The point is to read the file deliberately, not assume it's fine.

Exercise 14.21 †

(Guided.) On WordPress, an enabled Settings → Reading → "Discourage search engines from indexing this site" checkbox is the single most common cause of an accidental site-wide noindex — if you find it checked on a live site, that is very likely the highest-value fix available to you. On any platform, "View Page Source" and search for noindex: a <meta name="robots" content="noindex"> on a page you want ranked is an emergency. Record exactly which pages carry it and whether the exclusion is intended (a thank-you page: fine; a service or product page: fix today by removing the tag / unchecking the box, then request indexing).

Exercise 14.23 †

The line that should alarm you most is "Excluded by 'noindex' tag": 28 — includes the /pricing/ page. For a business that sells through its site, the pricing page is a money page; a noindex on it is a self-inflicted, high-value loss you can fix in minutes. Urgency ranking, most to least: (1) "Excluded by noindex" (28) — because it's hiding a page you want ranked; check whether it's a template/site-wide cause; (2) "Blocked by robots.txt" (7) — small, but verify none are real pages, and watch for the "indexed though blocked" backfire; (3) "Duplicate without user-selected canonical" (55) — a consolidation job (add canonicals), real but non-urgent; (4) "Crawled – currently not indexed" (120) — the biggest number but the least urgent, a content-quality signal (Chapter 12), and many of those pages were never going to rank. Triage by danger, not by count.

Exercise 14.25 †

The false claim is that "duplicate content triggers a Google penalty." In reality, for ordinary non-malicious duplication (URL variants, parameters, archives, syndication), Google simply picks one version to index and consolidates the rest — there is no penalty. The real costs are that Google may choose a version you didn't want, ranking signals get split across the copies, and crawl is wasted. The one case where duplication is penalized: deliberately deceptive duplication — scraped or spun content, and doorway pages designed to manipulate rankings. So: manage ordinary duplicates with canonicals; only intentional, manipulative copying earns a penalty.

Exercise 14.27

Blocking the confidential PDFs in robots.txt is ineffective because robots.txt only stops crawling, not access or indexing: anyone can open the files directly by URL, and if any link points to them Google can still index the URLs (as bare listings). It is a security risk because robots.txt is publicly readable — you have just published a tidy list of the exact paths you're trying to hide, which is an invitation to anyone curious. The correct fix: put the files behind authentication (password protection) so only authorized users can reach them; if they must be reachable but not indexed, use an X-Robots-Tag: noindex header on them (kept crawlable) — but truly sensitive files belong behind a login, not a robots rule.

Exercise 14.28 †

Three-step remediation, in priority order: (1) In the Millhaven sub-site's Settings → Reading, uncheck "Discourage search engines from indexing this site" — this removes the site-wide noindex that is very plausibly why non-branded pages don't rank. (2) Remove the leftover noindex from the four service pages (check the SEO plugin's per-page setting and the page source), then request indexing for each in URL Inspection. (3) Confirm in the Page indexing report over the following weeks that the pages move from "Excluded by 'noindex' tag" to "Indexed." This jumps ahead of the near-duplicate location pages because a noindex is an absolute block — those pages can rank for nothing while it's in place — whereas the near-duplicate location pages are indexed and competing, just not yet winning; you fix "can't play at all" before "playing but losing" (and the location-page fix is content/architecture work for Chapters 15 and 25, not a Chapter 14 toggle).

Exercise 14.29

Fix each source with the right control: for the empty tag archives, apply noindex (via the SEO plugin's archive settings) while keeping them crawlable, so Google reads the tag and drops them from the index; for the parameter URLs, add canonical tags pointing each parameter variant at its clean base URL, so Google consolidates signals instead of indexing duplicates. Do not simply Disallow them all in robots.txt, because these URLs are already discovered and indexed — blocking the crawl would freeze them in the index as bare listings ("Indexed, though blocked by robots.txt") and remove Google's ability to ever see the noindex/canonical that would actually clean them up. Block the crawl only after the junk is out of the index, if at all.

Chapter 15 — Worked Answers (daggered † and odd-numbered exercises)

Exercise 15.1

Crawl depth is the number of clicks (link hops) it takes to reach a page from the homepage by following on-page links. The homepage is depth 0; a page linked directly from it is depth 1, and so on.

Exercise 15.2 †

A flat architecture keeps most important pages a few clicks from the homepage (the site is "wide"); a deep architecture buries content many clicks down through nested layers (the site is "tall"). - Flat — advantage: pages are discovered and crawled easily, and homepage authority reaches them in few hops. Risk: pushed too far (a homepage/menu linking to hundreds of pages), it dilutes link equity across too many destinations and destroys navigational clarity. - Deep — advantage: it can express a genuine, logical hierarchy for a large, layered catalog (helpful to users when the categories are real). Risk: important pages end up crawled rarely and starved of equity, and users struggle to reach them. The resolution (§15.1) is neither extreme: a logical hierarchy with important pages kept shallow and nothing important stranded deep.

Exercise 15.3

Link equity is the ranking value (authority) a link passes from the source page to the target page. It is the internal expression of PageRank — the model (Ch 22) that treats links as votes of importance, where a page accumulates authority from links pointing to it and passes a share of its own authority through its outgoing links. "Link equity" is that same flowing authority as it moves between the pages of one site.

Exercise 15.5 †

An orphan page is a page that no other page on the site links to. It most often fails at the discovery stage of the pipeline (Ch 1): because Google finds pages mainly by following links, a page nothing links to may never be found or crawled — so its quality is never even weighed at the ranking stage. It also receives zero internal link equity (nothing points at it), so even if discovered via the sitemap it has no internal authority to help it compete.

Exercise 15.7

A breadcrumb does four jobs at once: (1) for the user — orientation ("where am I, and how do I get back up?"); (2) for the crawler — extra internal links up the hierarchy that reinforce the site's structure; (3) for link flow — it passes equity from every child page back up to its parent/category pages; (4) for the SERP — with breadcrumb structured data (Ch 18) it can render as a breadcrumb trail under your title.

Exercise 15.8 †

Because a page divides its authority among all its outgoing links (the §15.4 simplified model). A page with 5 outgoing links passes each destination roughly one-fifth of its equity; a page with 200 outgoing links passes each destination roughly one-two-hundredth — the same source authority split forty times thinner. So a link from a page that links to few things carries a much larger slice than a link from a page that links to hundreds. This is exactly why a 200-link stuffed footer is a weak way to "boost" a page, and why curated navigation concentrates authority where it matters.

Exercise 15.9

A crawl trap is a site structure that generates a near-infinite number of low-value URLs for Googlebot to crawl, wasting crawl attention (and bloating the index) on junk instead of real pages. Three common creators: (1) faceted navigation (filter/sort parameter combinations, e.g. ?color=&size=&sort=); (2) endless calendars (a "next month" link that continues forever); (3) session IDs / tracking parameters in URLs (the same page at countless unique URLs). (Internal search-result pages, if crawlable, are a fourth.)

Exercise 15.11

Two consequences of a money page sitting six clicks deep: (1) Crawl priority/discovery — Google treats distance-from-home as a rough importance signal and crawls deep pages less often, so the page is seen as less important and re-crawled slowly. (2) Link equity — authority thins as it travels through the link graph, so a page six hops from the well-linked homepage receives a much fainter share of the site's authority than a page linked directly. Both are mechanisms, not penalties: they follow from how discovery and link flow work.

Exercise 15.12 †

Adding the 75 links does not give each page "homepage authority" — it divides the same authority into more slices. Before: homepage authority ≈ 100 split across 25 links ≈ ~4 each. After: ≈ 100 split across 100 links ≈ ~1 each. Every previously-linked page now receives roughly a quarter of what it did, and the 75 new pages get a token slice. The homepage did not gain authority by linking more; it spread the same authority thinner and muddied its signal about which pages matter. It does not help — and it likely hurts the pages that were previously well-fed. Curate the nav to the few hubs that matter and let them link down.

Exercise 15.13

The 288 posts reachable only from a deep paginated archive are effectively near-orphans at high crawl depth: they receive almost no internal equity and are crawled rarely, so they can't compete. The hub-and-spoke fix (§15.6): group the 300 posts into topical clusters; create (or designate) a hub page per topic that links to every post in that cluster; have each post link back to its hub and to a few relevant siblings; and surface the hubs in the main navigation. This pulls the posts shallow, gives each internal equity and descriptive anchor text, and signals coherent topical coverage to Google.

Exercise 15.15 †

Cost-benefit (from §15.2): the benefit is a very small ranking hint (keywords in URLs are a minor signal, confirmed by Google) plus slightly more readable/clickable URLs. The cost is large: 40 indexed, traffic-earning URLs would change, breaking every internal and external link and every bookmark to them; each needs a carefully mapped 301 redirect, you risk redirect chains and missed mappings, and there is a temporary ranking wobble while Google reprocesses. Verdict: do not approve it to chase a keyword — the juice isn't worth the squeeze on working URLs. Condition under which you might: if a genuine restructure or migration is happening anyway (e.g., consolidating a broken taxonomy, an HTTPS move), fold the improvement in — but then do the full redirect-mapping discipline of Chapter 21, and change URLs once, not repeatedly.

Exercise 15.17 †

Before touching content, the two most likely architecture causes: (1) Orphan / under-linked page — if nothing (or almost nothing) links to it, Google found it late and treats it as unimportant. Check: Search Console → Links → Internal links (how many point to it?), and whether it's in the navigation or any related content. (2) Excessive crawl depth — it may be buried many clicks from home, crawled rarely. Check: click from the homepage counting hops, or run a crawler and read its crawl-depth column. (A discovery timeline showing it was found only three weeks ago is itself a strong orphan/deep-page signal.) Fix the architecture — link to it from strong, relevant pages and pull it shallower — before concluding the excellent content is the problem.

Exercise 15.19

40,000 indexed URLs for 1,200 products is index bloat from a crawl trap — almost certainly faceted navigation generating tens of thousands of near-duplicate parameter URLs (?color=, ?sort=, ?size=). The pipeline cost: Google wastes crawl attention on junk (and may struggle to identify the canonical category page among the duplicates), so the real category pages are crawled and consolidated less effectively. The fix is to keep the junk out of the crawl/index — robots.txt disallow patterns, canonical tags to consolidate, and/or noindex — the tools of Chapter 14, with faceted navigation specifically dived in Chapter 31.

Exercise 15.20 †

(Audit task — a strong answer contains:) the reader opens Search Console → Links → Internal links and reports (a) their five most-internally-linked pages; (b) an honest check of whether their priority commercial pages appear near the top (they often do not — that gap is the finding); and (c) at least one important page with fewer than three internal links. The single committed action: name one specific important, under-linked page and one strong, relevant source page from which they'll add a descriptive internal link this week. The learning point: the pages with the most internal links are your "loudest" pages to Google — they should be the ones you most want to rank.

Exercise 15.21

(Measurement task — a strong answer contains:) a click-count from the homepage to each of three important pages, using only on-page links. Any page deeper than three or four clicks is flagged with a reason (buried in a dropdown, reachable only via a deep archive, only linked from one obscure page). The insight: depth is often accidental — a page got buried as the site grew — and the fix is usually a single new link from a shallow, strong page (a hub or the homepage), not a rebuild.

Exercise 15.23 †

A curated main nav of six or fewer top-level items — organizing by service category and location, not by every individual service: Home · Heating & Cooling · Plumbing · Electrical · Locations · Guides (or "Blog"). - The individual services (AC repair/install, furnace repair/install, water heater, drain cleaning, panel upgrade, EV charger) live under their category hub (e.g., AC + furnace under "Heating & Cooling / HVAC"). - The four cities live under a Locations hub that links to each city page, which in turn links to the services offered there. This turns a 14-item wall into a scannable set of hubs, concentrates homepage authority on a handful of important destinations, and still reaches everything in two or three clicks.

Exercise 15.25 †

A "furnace problems" hub-and-spoke (one hub, links both ways, one honest cross-silo link):

HUB: "Furnace Problems & Repair"
  ├─▶ Spoke: "Furnace won't turn on"        ─┐  each spoke links BACK to the hub
  ├─▶ Spoke: "Furnace blowing cold air"      │  and to 1–2 relevant siblings
  ├─▶ Spoke: "Furnace short-cycling"         │
  ├─▶ Spoke: "How to relight a pilot light"  │
  └─▶ Spoke: "Furnace making a banging noise"┘
Honest cross-silo link: "How to relight a pilot light" → links to the PLUMBING silo's
"water heater pilot light" guide, because a reader with a gas furnace pilot issue may
genuinely want the water-heater pilot guide. Relevance justifies crossing the silo.

Exercise 15.27 †

The report shows the site's authority is pooling in the wrong places: the homepage, About, and Contact are massively over-linked (388–412 internal links each — likely sitewide header/footer links), while the priority commercial page (/services/plumbing/water-heater-replacement/) has only 2 internal links, and even a related blog post (47) outranks it internally. Top two moves: (1) Add internal links to the water-heater page from strong, relevant sources — the plumbing hub, the homepage's guides module, and the trafficked blog posts (which already have 47 links of their own to share) — with descriptive anchor text. (2) Reduce the noise: About and Contact almost certainly don't need to be in a link position that outranks your money pages; a curated nav (§15.3) rebalances where equity flows. (Bonus: the 47-link blog post is a perfect donor — it has authority and topical relevance.)

Exercise 15.29 †

The myth is "PageRank sculpting" with nofollow. It stopped working in 2009, when Google publicly changed how nofollow handles PageRank: a nofollowed link no longer redirects its share of PageRank to the other links on the page — that share simply evaporates. So nofollowing your footer/login/cart links does not funnel authority to your product pages; it loses the authority those links would have carried. The legitimate alternative (§15.5): send more authority to priority pages by linking to them more, from stronger and more relevant pages, with descriptive anchor text — and by linking to genuinely trivial pages less. Steer with real links, not with attributes that only lose you equity.

Exercise 15.31

The claim (never link between silos) is rigid-siloing folklore. Google understands topical grouping without you building walls, and refusing a genuinely helpful cross-topic link hurts the user for an imagined algorithmic benefit. The replacement rule: relevance, not rigid separation. Group related content and link it densely within a theme (the sound core of siloing), but whenever a cross-topic link genuinely serves the reader (a failing-water-heater article linking to a furnace-maintenance guide), make it. The purpose of the structure was to serve the reader in the first place.

Exercise 15.33 †

Making a site flatter is wrong when it collapses a genuine hierarchy into an undifferentiated dump — e.g., a homepage or mega-menu that links to 800 pages "so everything is one click from home." That harms users (an 800-link menu is unusable — no one can find anything) and link flow (the homepage's equity is split 800 ways, so each destination gets a vanishing slice, and Google gets no signal about which pages matter). The resolving principle: the goal is not "flat" or "deep" as a slogan but a logical hierarchy — related things grouped, important things shallow, nothing important buried, and nothing so wide that structure dissolves into noise. Flatness is a virtue only up to the point where it becomes a dumping ground.

Exercise 15.34 †

"Sump pump installation" is a plumbing service, so it lives under the plumbing hub: - Hierarchy: Home → Plumbing hub → Sump Pump Installation (→ its five city pages). - URL: /services/plumbing/sump-pump-installation/ (and city variants /services/plumbing/sump-pump-installation/cedar-hills/, etc.). - Not an orphan on day one: link it from the plumbing hub (its parent), add it to the plumbing section of the nav/hub listing, and add a relevant contextual link from at least one related page (e.g., a "basement flooding" or "drain cleaning" guide). Its crawl depth is 2 (home → plumbing hub → sump pump service); the city pages are depth 3.

Exercise 15.35

Honest two-sentence status update to the Delgados: "The water-heater page now matches what searchers want, covers the questions they actually ask, and — as of this month — finally gets internal links from your homepage, your new plumbing hub, and three of your popular guides, so it has every advantage the site can give it and is positioned to improve." "I won't promise a specific position, because that depends on links from other sites (which we'll work on next) and on competitors we don't control — what I can promise is that we've removed the fixable things that were holding a genuinely good page back."

Exercise 16.1

The three Core Web Vitals: LCP (Largest Contentful Paint) — how long until the largest visible content element is painted (the loading feel); good ≤ 2.5 s. INP (Interaction to Next Paint) — the delay from a user interaction to the next painted frame (responsiveness); good ≤ 200 ms. CLS (Cumulative Layout Shift) — how much visible content moves unexpectedly (visual stability); good ≤ 0.1. All are measured from real users at the 75th percentile, separately on mobile and desktop.

Exercise 16.3

CrUX is the Chrome User Experience Report, Google's public dataset of field data collected from opted-in real Chrome users. "75th percentile" means the reported value is the mark that 75% of real visits met or beat (25% were worse) — so it describes the slower end of the experience, not the median. "Trailing 28 days" means it is a rolling four-week average, so it lags recent changes: after a fix, the CrUX number takes weeks to fully reflect it.

Exercise 16.4 †

TTFB is Time To First Byte — the delay between the browser requesting the page and the first byte of the server's response arriving (essentially, how long the server takes to start answering). It caps LCP because it is the opening segment of the LCP timeline: the clock is already running before a single pixel is possible, so the largest element cannot be painted until after TTFB elapses. A 1.5 s TTFB alone consumes most of the 2.5 s "good" LCP budget before any image even begins to download.

Exercise 16.5

A render-blocking resource is a file — almost always CSS or JavaScript in the page <head> — that the browser must download and process before it can paint anything, so it delays the first paint and therefore LCP. Two ways to reduce its impact: defer or async the non-critical JavaScript so it loads without blocking, and inline the critical CSS (the small amount needed for the top of the page) while loading the rest afterward; also minify files to shrink them.

Exercise 16.7

Users first, rankings second: a slow page loses real customers right now through higher bounce and fewer conversions — a direct, often large business cost that exists whether or not Google ever notices. So speed is worth fixing purely as a UX/revenue problem; the ranking benefit is a genuine but secondary bonus. The one sentence for the boss: "Fixing speed will make us more money from the visitors we already have, and if it also nudges rankings — which is a modest tiebreaker, not a #1 button — that's a bonus on top."

Exercise 16.9 †

FID (First Input Delay) measured only the input delay before the browser began processing the user's first interaction — not the full time until the user saw a response, and not any interaction after the first. As a result almost every site scored well on it, so it couldn't distinguish good sites from bad. INP captures the full latency (from interaction to the next painted frame) across all interactions in the visit, reporting roughly the worst — a much truer picture of responsiveness. It's a clean example of theme 3 (evidence over folklore): Google retired its own metric because the evidence showed it flattered everyone and revealed nothing, replacing it with a stricter, more honest one.

Exercise 16.11

A tiebreaker signal is one that helps decide between candidates that are otherwise comparable — here, pages Google judges roughly equal in relevance and quality — rather than one that can vault a weak page over a strong one. A page with worse Core Web Vitals should still outrank a page with better ones whenever it is meaningfully more relevant, more complete, or more authoritative: per Google's own framing, page experience does not override great, relevant content, so the slower-but-better page correctly wins.

Exercise 16.13

Honest rewrite: "Our page passed Core Web Vitals in the field, which is good for users and clears a modest ranking tiebreaker — but the 100 is a lab score Google doesn't rank on, and ranking #1 depends mostly on being the most relevant, highest-quality result against everyone else competing for the term, which no speed score can guarantee."

Exercise 16.15 †

The failing vital is INP (responsiveness): LCP (loading) is fine ("looks loaded fast") and CLS (stability) is fine ("never jumps"), so the problem is the page reacting slowly to interaction. The likely cause is JavaScript blocking the main thread — a heavy or third-party script busy when the user taps, so the tap has to wait in line. The "doesn't work the first time" symptom is classic: the first tap registered but couldn't be painted quickly, so the user tapped again. Fix by reducing/deferring JavaScript, especially non-essential third-party scripts, and breaking up long tasks (§16.6).

Exercise 16.16 †

The failing vital is LCP (loading feel): the largest element (the hero photo) takes ~4 s to appear and the screen is blank until then. The two most likely culprits: (1) a slow server response (TTFB) delaying everything, and/or (2) a heavy and/or lazy-loaded hero image — a large file in the wrong format, or one that has been lazy-loaded (telling the browser to wait to fetch the very image LCP is timing). Fixes: cache/CDN the response, and serve a right-sized modern hero image that is not lazy-loaded (image specifics in Chapter 11).

Exercise 16.17

The failing vital is CLS (visual stability): content shifted as an image loaded, moving the link under the user's thumb. The one-line fix: set explicit dimensions on the image (width/height or CSS aspect-ratio) so the browser reserves its space up front and nothing jumps when it loads. (More broadly, reserve space for any late-loading element — ads, embeds, banners.)

Exercise 16.19

Two reasons the field INP is worse than the developer's experience: (1) Device gap — the developer is on a fast laptop/phone with a powerful processor, while real users are often on slower, cheaper, older devices where the same JavaScript takes much longer to run on the main thread; INP is dominated by that main-thread work. (2) Interaction gap — the developer may barely interact, while real users tap menus, filters, and buttons repeatedly, and INP reports roughly the worst interaction across the visit; a synthetic experience that never really interacts understates it. This is exactly why field data (which captures real interactions on real devices) matters more than a lab run for INP.

Exercise 16.21 †

(Guided — answers vary by site.) The deliverable is the field-first read. Example: "PageSpeed Insights, Mobile: field-data Core Web Vitals FAILED, LCP red at 3.9 s (INP 190 ms good, CLS 0.08 good); lab performance score 71. My real problem is LCP on mobile — a loading-speed issue, most likely server response and the hero image — not the lab score." The key skill being checked: stating the problem from the field assessment and the failing vital, and explicitly not treating the lab number as the problem.

Exercise 16.23

(Guided.) The deliverable is one sentence naming what shifted and the fix. Example: "On a throttled connection the headline held, but when the top banner image loaded it shoved the article down and my tap missed — I'd reserve space for that image with explicit width/height so it stops jumping." If nothing shifts, that's a passing qualitative CLS result; note it and move on. Answers vary by site and platform.

Exercise 16.25 †

No — do not spend the afternoon chasing 68 → 100. The field data already says PASSED (LCP 2.2 s, INP 170 ms, CLS 0.05 are all good), which means real users are having a good experience and the Core Web Vitals ranking assessment is satisfied. The 68 is a lab score Google does not rank on; the two measure different things, and here the field verdict is the one that matters. What you would actually do: nothing for ranking's sake — bank the passing field result and redirect the time to content, intent, and links. (You could note the lab "Opportunities" for later, but only act on them if the field data were failing.)

Exercise 16.27

Three bundled falsehoods. (1) "A perfect 100 score" — that's the lab (Lighthouse) score; Google's ranking signal uses field data (CrUX), which a perfect lab run doesn't guarantee. (2) "The #1 ranking factor" — Core Web Vitals is a modest tiebreaker, per Google, not the top factor; relevance, quality, and authority dominate. (3) "You'll dominate Google" — ranking is a relative contest, so no score entitles you to top positions; you can pass Core Web Vitals and still lose to more relevant competitors. Truth in one line: passing Core Web Vitals in the field is good for users and a small ranking tiebreaker — not a lab number, not the biggest factor, and not a guarantee of anything.

Exercise 16.29 †

(a) Homepage — failing LCP and CLS: highest-leverage fix is the hero image (right-sized modern format, don't lazy-load it) for LCP, plus reserving space for the promo bar for CLS. (b) "AC repair" page — failing INP: highest-leverage fix is to cut/defer JavaScript — audit the nine plugins and the third-party scripts, remove the unused ones (several inherited from the old "SEO guy"), and defer the rest. (c) Location pages — "insufficient field data" means too few real visitors for CrUX to report; this is not a speed problem a CDN can fix, because the issue is that almost nobody is visiting the pages to generate field data. It is a visibility/content problem — thin location pages that don't rank — owned by Chapter 15 (architecture) and Chapter 25 (local SEO), not this chapter.

Exercise 17.1 †

Mobile-first indexing is Google's practice of predominantly using the mobile version of a page's content to index and rank it. Google crawls primarily as Googlebot Smartphone (a crawler that identifies as a mobile device and renders the page at a phone-sized viewport), and whatever it finds in that mobile fetch is what enters the single index. Practical upshot: content that appears only on the desktop layout is at real risk of never being indexed, and unindexed content cannot rank.

Exercise 17.3 †

The three configurations: (1) Responsive design — one URL and one HTML document per page whose layout reflows to any screen with flexible CSS. (2) Dynamic serving — one URL, but the server sends different HTML to phones and to laptops based on the detected device. (3) Separate URLs (m-dot) — an entirely separate mobile site (e.g., m.example.com) with its own addresses. Google recommends responsive design because it makes content parity automatic (there is only one HTML document, so mobile and desktop cannot drift apart), consolidates all signals on one URL, needs no error-prone device detection, and is a single codebase to maintain.

Exercise 17.5 †

The viewport meta tag (width=device-width, initial-scale=1) tells a mobile browser to size the page to the device's actual width so the responsive layout can arrange itself for a phone. Without it, a mobile browser assumes the page was built for a desktop, renders it at a wide desktop width, and then shrinks the whole thing to fit the screen — leaving text microscopic and forcing the user to pinch-and-zoom to read anything. A missing or misconfigured viewport tag is the most common single cause of a page being "not mobile-friendly."

Exercise 17.7

The four signals and their good states: Viewport — the width=device-width tag present so the page sizes to the screen. Tap targets — large enough (~48px) and spaced enough (~8px) that a fingertip hits them reliably. Font size — body text readable without zoom (~16px base). Interstitials — no content-covering pop-up when a user arrives from mobile search (legal notices and login dialogs excepted). (Bonus, from the checklist table: no horizontal scrolling — content fits the viewport width.)

Exercise 17.8 †

A responsive site has exactly one HTML document per page, served to phone and laptop alike; the mobile and desktop versions are the same file, so they cannot fall out of content parity by construction. An m-dot site maintains two separate HTML documents (and effectively two whole websites) for every page — the desktop version and the mobile version at a different URL. In the real world those two versions drift: someone updates a service description or adds a schema block on the desktop site and forgets the m-dot, and over time the mobile version — the one Google indexes under mobile-first indexing — becomes the thinner, staler twin. Two documents to keep aligned forever is a far higher parity risk than one.

Exercise 17.9

Two reasons: (1) Networks — phones are often on slower, higher-latency, more variable cellular connections, so loading metrics like TTFB and LCP suffer relative to a wired desktop. (2) Processors — phone CPUs (especially mid-range and older ones) are weaker than laptop CPUs, so the page's JavaScript takes longer to execute, which particularly hurts INP (responsiveness), a metric driven heavily by main-thread work. (Both are why Google's field data leans mobile and why the mobile column is the one closest to what's assessed.)

Exercise 17.11 †

The mobile score is closer to what Google actually assesses for ranking. Under mobile-first indexing Google reads and evaluates the mobile version, and the Core Web Vitals ranking assessment is built on field data (from CrUX) that, for most sites, is dominated by real mobile visits. So a page that "passes on desktop" but fails on mobile is, for ranking purposes, a page that fails — the flattering desktop number is largely beside the point. Judge pages by their mobile numbers.

Exercise 17.13 †

"You still need AMP" is outdated because AMP's single biggest incentive was removed. The specific change: the Page Experience update (rolling out on mobile through 2021) opened Top Stories eligibility to any page — AMP or not — that meets the news policies and provides a good page experience; the AMP badge was also retired. AMP was never itself a ranking factor, so once the Top Stories requirement was gone, there was no SEO rationale left. What replaced it: a fast, standards-based responsive page that passes Core Web Vitals — which achieves the same speed on your own URL, with full control, and a single codebase.

Exercise 17.15 †

Diagnosis (pipeline terms): this is not a ranking-tactics problem first; it is a parity/indexing problem. Because Google indexes the mobile version, the ~1,100 words, the ~35 reviews, and the Review + FAQ schema that appear only on desktop are effectively absent from what Google reads — the page is competing on a fraction of its real substance, so it loses to competitors whose full content is in their mobile HTML. Fix order: (1) Restore the full description and the reviews to the mobile HTML (present in the HTML even if visually collapsed, not fetched by JS only after a tap). (2) Put the Review and FAQ schema on the mobile version. (3) Restore the missing internal links on mobile. (4) Re-inspect with URL Inspection's rendered HTML to confirm Google now sees it all. Only after parity is restored does normal on-page optimization (Ch 9) apply — you cannot out-optimize content the indexed version doesn't contain.

Exercise 17.16 †

Before touching rankings or content, check the mobile conversion path, because the symptom is "traffic doesn't become calls," not "no traffic." First: is the phone number a tappable tel: link, visible without scrolling? If it's plain text or an image buried below the fold, mobile visitors have to work to call — the leak is at the conversion, not the ranking. Second: is anything blocking or delaying the content on arrival — an intrusive pop-up covering the page, or a slow load on a weak signal that loses people before they see the number? Both are mobile-usability failures that throttle calls regardless of ranking. Fix the tap and the friction before assuming you need more traffic.

Exercise 17.17 †

The risk: content loaded via JavaScript only after a tap on "Continue reading" may not be in the mobile HTML that Googlebot Smartphone reads — so the author bio (an E-E-A-T signal), the comments, and half the body text could be effectively invisible to the index. Under mobile-first indexing, that's a genuine content-parity failure: the page ranks on far less than it appears to contain, and it may lose author/experience signals it needs. How to confirm: use URL Inspection (Chapter 27) to view the rendered HTML for the mobile crawl and Ctrl-F for text you expect from the bio and body; if it isn't there, Google isn't seeing it. The fix is to ship that content in the HTML (visually collapsed is fine), not fetch it on demand.

Exercise 17.19

What's right: the mobile version is indeed what Google indexes and ranks. What's wrong: the conclusion. "Desktop is irrelevant" is false on two counts. First, desktop matters enormously to the humans who use it. Second — and decisive here — deleting the spec table from desktop only misunderstands the problem; the real risk is a table that exists on desktop but not in the mobile HTML, because that's the version Google reads. The correct move is the opposite of deletion: ensure the spec table is present in the mobile HTML so Google indexes it. Removing useful, indexable content to "simplify" is throwing away substance the page ranks on.

Exercise 17.20 †

The full cost: an image can't be tapped to dial and its text can't be read by assistive tech or reliably parsed as a number, so a mobile visitor in an emergency must select the number from an image (often impossible), or read it and manually switch to the phone app and type it — a multi-step detour at the exact moment they're anxious and impatient, with a chance to abandon at every step. For an emergency home-services business whose customers are, by definition, on phones in a hurry, that friction sits directly on the conversion. The one-line fix: render the number as a tappable link — <a href="tel:+15551234567">(555) 123-4567</a> — visible without scrolling (and ideally sticky on mobile).

Exercise 17.21 †

(Guided — answer varies by site.) The deliverable is one sentence recording whether width=device-width appears in your homepage source. Example (pass): "View Source shows <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\"> — viewport is correctly set, so this isn't my problem." Example (fail): "No viewport tag in the source — this is my highest-priority mobile fix; without it the page renders at desktop width and shrinks, forcing pinch-to-zoom." On WordPress this is normally supplied by the theme, so most students will pass — the value is in confirming rather than assuming.

Exercise 17.23 †

(Guided — answer varies by site.) The deliverable is a timed, written record of friction on your phone completing the primary action one-handed. A strong answer names specific friction points and ties each to a section: e.g., "Took 41 seconds to call: a newsletter pop-up covered the screen on arrival (interstitial, §17.4); the phone number was plain text I had to copy (no click-to-call, §17.6); the 'Book' button sat beside two other links and I mis-tapped twice (tap targets, §17.4)." The point is to feel the page as a hurried thumb-first user, then convert each friction point into a prioritized fix.

Exercise 17.25 †

In Figure 17.2, the elements effectively invisible to Google (present on desktop, absent from the mobile HTML) are: roughly 1,100 words of the description, about 35 of the 38 reviews (loaded via JS only after a tap), the Review and FAQ schema, and 9 of the 12 internal links. Priority fix order: (1) the primary description text — it's the substance the page ranks on and the biggest missing block; (2) the reviews content into the mobile HTML — real substance and it restores the Review schema's basis; (3) the Review + FAQ schema on the mobile version — restores rich-result eligibility; (4) the 9 internal links — restores authority flow to related pages. Rationale: restore raw indexable content before the signals that depend on it, then re-inspect to confirm parity.

Exercise 17.27

(Guided/research — answer varies.) A strong answer names a real page and walks the exact friction: e.g., "On [site], the number is plain text in the footer. On my phone I must: long-press to select it (the selection handles grab the wrong characters twice), tap 'Copy,' leave the browser, open the Phone app, tap the keypad, paste, then tap call — six steps." The lesson to state: every one of those steps is a chance to abandon, and a one-tap tel: link collapses all of them into a single action.

Exercise 17.28 †

The myth: "Content behind tabs/accordions is discounted on mobile, so show everything expanded." Why it's wrong now: it was partly true before mobile-first indexing, when hidden content could be given less weight — but that reasoning flipped with the device. Under mobile-first indexing, Google treats content that is in the HTML but visually collapsed behind tabs or accordions as fully indexed and normally weighted, because on a small screen, collapsing content into expanders is good, responsible UX. The accurate rule: collapse for readability freely — just make sure the collapsed content actually ships in the mobile HTML, not fetched by JavaScript only after a tap. The deciding factor is where the content lives, not whether it's visible by default.

Exercise 17.29

Every questionable claim: "Required for mobile rankings" — false; AMP is not a ranking factor and is no longer required for Top Stories (the Page Experience update removed that). "\$6,000" — you'd be paying to build and maintain a second, constrained codebase for a benefit that no longer exists; a fast responsive page passing Core Web Vitals achieves the same speed. "We guarantee you'll jump to page one" — the reddest flag of all: no one can guarantee a ranking; ranking is Google's decision against competitors the vendor doesn't control, and a guarantee is the signature of snake oil. Ethics: the pitch bundles an outdated technical claim with an impossible promise to extract a large fee — it's the kind of misinformation this book exists to inoculate against. The honest advice to Rivertown: skip AMP; invest the money in the click-to-call/parity fixes and the Core Web Vitals work that actually help.

Exercise 17.30 †

(Model answer.) Top two fixes by return on effort: (1) Click-to-call and (2) content parity (restore the hidden service-area lists and footer NAP to the mobile HTML). Order and justification: click-to-call is first and it isn't close — Rivertown is an emergency home-services business whose customers are on phones in a hurry, the site currently renders its number as an image, and converting it to a one-tap tel: link is minutes of work that removes friction from the exact action every "no heat" searcher is trying to take. Parity is second because content Google can't see on mobile can't help Rivertown rank, but it's a slightly larger job and its payoff is downstream (visibility, not an immediate conversion). What each does / does not settle: Click-to-call settles the mobile conversion friction on the phone number; it does not bring more traffic or win the local pack (that's Chapter 25). Parity settles what Google can see of Rivertown's mobile pages; it does not by itself add the LocalBusiness/Service/FAQ schema those pages need (Chapter 18) or make them fast (Chapter 16). Add both to the Strategy File as the chapter's mobile layer — handicaps removed, not yet the mobile win.

Exercise 18.1

Structured data is standardized, machine-readable labeling added to a page that states outright what its content means, running alongside the visible page for machines to read. Its two jobs: (1) make meaning explicit — help Google understand the page and connect it to the right entities/topics (Ch 4); and (2) make the page eligible for rich results — enhanced listings (stars, breadcrumb, etc.). Job one is more durable, because it doesn't depend on Google offering a visible feature and can't be revoked by a feature announcement (as job-two features were in 2023); job two is visible but at Google's discretion.

Exercise 18.3 †

A rich result is a search listing enhanced beyond the plain title-URL-description with extra visual elements drawn from your structured data. Three examples: star ratings, a product image thumbnail, and a price (or a breadcrumb trail, or expandable questions). It replaced the older term "rich snippet." Key caveat to include: marking up a page makes it eligible for a rich result; Google decides per query whether to show one — it is never guaranteed.

Exercise 18.5

The two older syntaxes are Microdata and RDFa (Resource Description Framework in Attributes), both of which weave labels into the visible HTML via extra tag attributes. Google recommends JSON-LD because it is a separate, self-contained block decoupled from the visible markup — easy to add, update, generate from a template, inject via a tag manager, and validate on its own, and it doesn't break when the page's design changes. (Microdata/RDFa remain valid, so existing sites needn't migrate urgently.)

Exercise 18.7 †

For a non-technical owner: when Google infers, it is reading your words and making its best guess that the page is about a plumber in Cedar Hills — usually right, but a guess, and guesses can be wrong or incomplete. When you use structured data, you tell it directly, in a fixed format it can't misread: this is the business name, this is the address, these are the hours. Telling beats hoping because it removes ambiguity for facts that have exact values (address, phone, price, hours), and because it lets Google connect your page confidently to the real-world entity behind it. It doesn't make the page rank higher — it makes the machine's understanding certain instead of estimated, which is the foundation everything else builds on.

Exercise 18.9

Calling schema a "ranking factor" confuses affecting the listing with affecting the rank. Google has said repeatedly that structured data is not a direct ranking factor. The honest chain: markup → eligibility for a rich result → maybe Google shows the rich result (Google decides, per query) → maybe the more prominent listing earns more clicks (depends on the query and the SERP). Every "maybe" is a decision Google makes, and none of them is "the page moves up." A more clickable listing can help traffic without changing position at all.

Exercise 18.10 †

Two reasons "more markup on every page" is wrong. Eligibility: adding types that Google doesn't turn into rich results (e.g., Service) produces nothing visible, and adding types that don't match the page produces nothing either — effort with no payoff. Risk: marking up content that isn't on the page, isn't true, or misrepresents the page violates Google's structured-data guidelines and can trigger a "Spammy structured markup" manual action, which removes rich results and can suppress the page. Correct, specific, true markup beats maximal markup every time.

Exercise 18.11

A rich result can reduce clicks when it answers the searcher's question in the SERP itself, so the user gets what they needed without clicking through — the "zero-click" dynamic. A fully expanded FAQ block is the clearest case: the answer is right there. This is part of why Google restricted FAQ rich results in 2023 — the feature could satisfy the query in place, which doesn't serve the publisher who provided the answer, and the feature was also being abused. So "bigger listing" is not automatically "more traffic for you."

Exercise 18.13

JSON-LD's strength is that it is a separate block, decoupled from the visible HTML: you can add, edit, template, and inject it without touching the page's design, and it won't break when the layout changes. That same decoupling is its trap: because the markup is separate, it's trivially easy to make it say something the page doesn't show — claim hours, a price, a rating, or FAQ content that no human can see. Google's guidelines forbid exactly that, and a markup-versus-page mismatch is mechanically detectable, so the convenience that makes JSON-LD great is the same property that makes dishonest markup easy — and easy to catch.

Exercise 18.14 †

Nothing will appear as an FAQ rich result. Since 2023, Google shows FAQ rich results only for well-known, authoritative government and health websites; a dentist's marketing pages don't qualify, so the expandable FAQ block won't render regardless of how cleanly the markup validates. The markup isn't wrong or harmful — it can still help Google understand the page's Q&A content (job one, meaning) — but expecting the SERP feature is chasing a snippet that no longer exists for this kind of site. (If the FAQs exist only to feed the dead snippet and add nothing for users, consider removing them.)

Exercise 18.15 †

No stars will appear. Since 2019, Google does not show review rich results for self-serving reviews — a business's own AggregateRating about itself, via LocalBusiness or Organization. The governing rule: review stars come from reviews on specific supported types (Product, Recipe, Course, Event, etc.) or from independent review platforms — not from a business rating itself. The real path to stars next to a local listing is earning reviews on the Google Business Profile (Ch 25), not writing self-serving markup.

Exercise 18.17

Yes, the markup is working — Google is reading breadcrumb structured data on 120 pages. The 8 "invalid (missing field 'item')" are a specific, fixable bug: those pages' BreadcrumbList items are missing the required item (URL) field, so they're ineligible for the breadcrumb rich result. First move: identify the 8 URLs (often a single template or CMS edge case produces all of them), fix the template so every ListItem includes a valid item, then let Search Console re-validate. It's a template-level fix, not eight separate ones.

Exercise 18.19

The risk: structured data injected by a tag manager exists only after JavaScript runs, so Google must render the page to see it — and rendering is the delayed, sometimes-imperfect step from Chapter 1 that gets full treatment in Chapter 19. Markup that ships in the raw server HTML is seen immediately and safely; markup that appears only after client-side script is markup you're betting Google will render promptly and correctly. The connection is the rendering / two-wave indexing problem: test the rendered page (URL Inspection / Rich Results Test), not just the source.

Exercise 18.20 †

(Guided — varies by site.) Deliverable: for the homepage and one inner page, record (a) which structured-data types the Rich Results Test detects, (b) whether the page is eligible for any rich result, and (c) any errors/warnings. Example interpretive sentence: "Homepage emits Organization + BreadcrumbList from the theme; the inner service page has no markup and is eligible for nothing — a gap to fill with a specific LocalBusiness/Service block." The point is to establish a baseline, not to fix anything yet — and to notice whether the detected @type is as specific as it could be.

Exercise 18.21

(Guided — varies by site.) The Schema Markup Validator checks whether the markup is valid Schema.org at all; the Rich Results Test checks whether the page is eligible for a Google rich result and whether the markup is valid to Google. Where they differ, the usual reading is: valid in the Validator but "no rich results" in the Rich Results Test = the markup is fine but the type has no Google rich result (e.g., Service) — meaning-only markup working as intended. Error in the Rich Results Test but valid in the Validator = the markup is valid Schema.org but missing a field Google requires for its feature. This is exactly how you distinguish "valid but not a Google feature" from "actually broken."

Exercise 18.23

(Guided — varies by site.) In Search Console → Enhancements, list every rich-result type Google is reading (commonly Breadcrumbs, Merchant listings/Product, and a sitewide Organization detection) and note any items marked invalid with their reason. The absence of a report for a given type usually means either you emit no such markup or Google offers no feature for it (e.g., no FAQ report for an ordinary site). If you lack access, record that Search Console setup is the Chapter 27 task and when you'll do it. The habit to build: glance at Enhancements in your weekly review, because structured data breaks silently.

Exercise 18.24 †

• The real bug: "Product (Merchant listings): 480 valid, 52 invalid — Missing field 'price'." Fifty-two product pages have Product markup lacking a required price, so they're ineligible for the merchant/product rich result. Fixable — usually a template or data-feed issue producing all 52; add the price field (populated from the real product data) and re-validate.
• The misunderstanding: "Review snippets: 0 valid — site marks up self-serving business reviews." No Search Console fix will produce these stars, because Google doesn't display self-serving business reviews (the 2019 rule). The "0" isn't a bug; it's the policy. The site should stop expecting stars from self-marked-up testimonials and instead earn reviews on its Google Business Profile (Ch 25).

Exercise 18.25

A plain listing shows title, URL, and two lines of description. A rich listing for cordless drill review adds, from a Product block: stars + rating count (aggregateRating), a price (offers.price), an "in stock" line (offers.availability), and possibly a thumbnail image (image) — occupying far more vertical space, especially on a phone. Honest note: "bigger" doesn't always help the owner of the listing. If the enhancement answers the query in place (or if a rating is mediocre and now visible), it can cost clicks; and the star display depends on genuine, supported reviews, not self-serving markup.

Exercise 18.27 †

Each proposal violates a documented Google guideline: - Hard-coding AggregateRating to "4.8" = fake/self-serving review markup (and self-serving business reviews aren't displayed anyway, per the 2019 rule). - FAQ content in the JSON-LD that isn't on the visible page = marking up content invisible to users. - Together these describe irrelevant/misleading markup that misrepresents the page. All three risk a "Spammy structured markup" manual action, which removes rich results, can suppress the pages, and requires fixing the markup plus a reconsideration request (Ch 26) to recover — and the violations are mechanically checkable (Google can compare the rendered page to the markup). What to tell the client: mark up only what's true and visible; relabel honestly; and earn real reviews on the Google Business Profile — the only legitimate route to the stars they want.

Exercise 18.29 †

A workable plan for the Cedar Hills branch: - (a) Type: use HVACBusiness (a specific Schema.org subtype of LocalBusiness) rather than the bare LocalBusiness, because the more specific accurate type tells Google more about what the business is. (If a branch is primarily plumbing or electrical, Plumber/Electrician would fit.) - (b) Core fields: name ("Rivertown Home Services — Cedar Hills"), url (the location page), telephone, a structured PostalAddress, openingHours, geo coordinates, priceRange, and areaServed. - (c) sameAs: the authoritative URLs for that branch's real profiles — its Facebook page, its Google Business Profile / Yelp listing, its LinkedIn — telling Google these all refer to the same entity (Ch 4). - (d) Honest sentence for the Delgados: "This markup states our Cedar Hills location's details clearly for Google and reinforces our NAP consistency, but it will not, by itself, put us in the local pack — that comes from our Google Business Profile, reviews, and proximity, which we tackle in the local-SEO work (Ch 25)."

Exercise 19.1

Client-side rendering: the HTML is produced in the user's browser, after JavaScript downloads and runs — the server sends only a shell. Server-side rendering: the HTML is produced on the server, per request, and arrives already filled with content (the browser then hydrates it). Static site generation: the HTML is produced on the server at build time (once, when you publish) and served as static files. The axis is when and where the HTML comes into being — browser/now, server/per-request, or build/ahead-of-time.

Exercise 19.2 †

The two-wave index is Google's decoupling of crawling from rendering: in the first wave it indexes whatever is present in the raw HTML immediately; content that needs JavaScript is put in a render queue and indexed in a second, later pass. Content in the raw HTML is indexed in wave one with no dependency on anything running. Client-rendered content exists only after the render — so it must wait for the second wave and is exposed to that step's delay, partial completion, or outright failure. In short: HTML content is indexed on the strength of being fetched; client-rendered content is indexed only on the strength of being successfully rendered later, which is a bigger "if."

Exercise 19.3

Three things the Web Rendering Service does not do, each with a content pattern it can hide: (1) it doesn't scroll — content loaded by infinite scroll may never trigger; (2) it doesn't click — text behind a "Load more" button, or in a tab/accordion that fetches on click, may never load; (3) it doesn't log in or keep state — content behind authentication, or gated by localStorage/sessionStorage/cookies, is invisible. (Also acceptable: it doesn't hover — hover-revealed content; it doesn't wait indefinitely — content after a slow API call.) The unifying test: "does this appear for a fresh, impatient, non-interacting visitor?"

Exercise 19.4 †

Hydration is the step in which a JavaScript framework attaches to HTML that was already rendered (by the server or at build time) — wiring up event handlers and making the static markup interactive — without rebuilding it from scratch. Because the server already sent fully-formed HTML, a crawler (or a user) sees the correct, complete content the instant the page arrives; the interactivity is layered on a moment later when the JavaScript loads and hydrates. So indexing rides on the HTML, which is present immediately, while the "app-like" behavior is a non-blocking enhancement. (Note: hydration itself has a cost that can affect INP — Chapter 16.)

Exercise 19.5

Dynamic rendering serves pre-rendered HTML to bots and client-rendered JavaScript to users. The single condition that keeps it from being cloaking: the content served to bots and to users must be substantively equivalent — the pre-rendered version is the same content, just delivered as finished HTML for the machine that renders poorly. The moment the bot version differs in substance from the human version (e.g., extra keywords, different text), it is cloaking, which is a policy violation.

Exercise 19.7 †

What's true: Google renders JavaScript with an evergreen, Chromium-based engine, and thousands of React sites rank perfectly well — the library is not the problem. What's misguided is treating "we use React" as the SEO-relevant fact. The relevant fact is the rendering mode: a React app that is server-rendered or statically generated (e.g., via Next.js/Gatsby) puts its content in the HTML and indexes cleanly, while a purely client-rendered React app ships an empty shell and takes on real risk. So the real question is not "React or not?" but "will our indexable content be in the initial HTML response, before JavaScript runs — and have we verified it?"

Exercise 19.9 †

Most to least reliable for getting content indexed: (1) Static site generation — the HTML is pre-built and served as static files, with no render dependency and nothing to fail at request time. (2) Server-side rendering — the HTML is rendered per request and arrives complete; slightly more moving parts than static (a live server must render each request), but content is still in the HTML. (3) Dynamic rendering — bots get pre-rendered HTML, so Google usually sees content, but it relies on a separate, brittle bot-serving pipeline that can drift or break, and Google discourages it. (4) Client-side rendering — content exists only after Google renders in the second wave, exposing it to delay, partial rendering, and failure. The ordering tracks a single question: how sure are we the content is in the HTML the consumer receives?

Exercise 19.11 †

This is not dynamic rendering — it is cloaking. Dynamic rendering serves bots the same content as users, merely pre-rendered; here the proposal is to serve Googlebot different, keyword-rich content that users never see, which is precisely the definition of cloaking. The risk: cloaking is a clear violation of Google's spam policies and can earn the site a manual action or algorithmic demotion — a potentially catastrophic, self-inflicted loss. The correct move is to serve users and bots the same content (server-render it if the concern is that Google can't see it), never a bot-only variant designed to influence rankings. (Understand-and-avoid: we name this to recognize and refuse it, not to do it.)

Exercise 19.13 †

Next two free checks, in order: (1) The site: phrase search. Take a distinctive sentence you can see on the rendered page, quote it, and search Google (optionally ... site:yourdomain). If the page comes back, the content was indexed despite the empty source — Google rendered it — and the issue is elsewhere (ranking, not visibility). If nothing comes back for a live page, that's strong evidence Google does not have the content. (2) URL Inspection (Search Console). Inspect the URL and read the rendered HTML and the list of page resources. If the content is in the rendered HTML, Google saw it; if it's missing, the blocked/failed-resources panel usually points at the cause (a blocked script folder, a failing API, a render timeout). Order matters: the free site: test often answers the question in seconds; URL Inspection confirms it and explains why.

Exercise 19.15 †

Cause: the "Load more" button reveals products 13–60 only when a user clicks it, and Googlebot does not click — so it indexes only the ~12 products present on initial load (Failure 2). Two fixes that keep the button for users: (1) provide real paginated URLs (/category?page=2, /category/page/2) with genuine <a href> links, so every product sits on a crawlable page even though users still get the button; and (2) render more/all of the products into the initial HTML (or load them on page-load rather than on click), so the content is present without any interaction. Either way, the interaction becomes an enhancement for humans, not the only path to the content.

Exercise 19.17 †

Two reasons the render could complete without the API-fetched paragraph: (1) the third-party API was slow or timed out during Google's bounded render window, so the render finished before the data arrived; (2) the API call failed or the script errored (a blocked resource, a CORS/network error, an exception), so the paragraph never populated — and Google indexed the page as rendered, minus that block. (Either way, the WRS does not wait indefinitely.) The architectural change that removes the risk: render that paragraph server-side (SSR) or at build time (SSG) so it is in the HTML before any client-side fetch — the content no longer depends on a live API call succeeding inside Google's render budget.

Exercise 19.19 †

(Guided — answer varies by site.) The deliverable is a one-sentence verdict on your most important page. Procedure: open the page, View Page Source (Ctrl+U), then Ctrl+F for a distinctive sentence you can see on screen. If you find it in the source, write: "Core content is in the raw HTML — no rendering dependency; safe." If the source is mostly script tags and an empty container and your visible text is absent, write: "Core content is JavaScript-built — verify with the site: phrase search and URL Inspection (§19.5)." The point is to replace "it's probably fine" with a checked statement.

Exercise 19.21 †

(Guided.) In Chrome DevTools, open the command menu (Ctrl+Shift+P), type "Disable JavaScript," then reload. Record everything that vanishes. For each vanished item decide whether Google must see it: body content, headings, and internal links → yes, Google must see these (if they depend on JS, that's a real exposure to verify); a carousel animation, a chat widget, a booking tool → no, these are interactive enhancements Google needn't index. Remember this is a pessimistic test — Google does run JavaScript — so "blank with JS off" is a worst case, not a verdict; but anything critical that disappears is something you are trusting the render step to deliver, and important pages should ideally survive even this harsh test.

Exercise 19.23 †

(Guided.) Visit yourdomain/robots.txt and scan the Disallow: lines for any folder that holds JavaScript or CSS — common culprits are /assets/, /static/, /js/, /wp-content/ (on older setups), or a build-output directory. If one is blocked: on a client-rendered site this is serious, because Google can't fetch the scripts it needs to render and will index the near-empty shell; even on a server-rendered site, blocking CSS/JS can stop Google seeing the page as users do. Write down what's blocked and why it matters. If only admin/cart/search paths are disallowed and nothing resource-related is, write: "robots.txt blocks non-content paths only — no rendering resources blocked; fine." (This is the Chapter 14 warning, applied to rendering.)

Exercise 19.25 †

(a) Yes — the rendered HTML shows the full grid of 24 products with names, prices, and links, so Google saw the products on this render, and coverage confirms the URL is indexed. (b) You would not call it "safe" because indexing rides on a live render succeeding: the flagged "Other error" on the third-party reviews-widget script is a warning that a slow or failing third-party resource, or an API timeout, could cause a future render to complete empty — and one green light on one page is not proof across the whole catalog. (c) The move: move the critical product content to server-side rendering or static generation so it is in the HTML and indexing no longer depends on a live render (and spot-check several templates + run site: phrase tests to confirm at scale).

Exercise 19.27 †

Both are wrong because they sit at opposite extremes of a spectrum whose truth is in the middle. "Google can't read JavaScript, avoid React" is false and outdated — since 2019 Googlebot renders modern JavaScript with an evergreen Chromium engine, and countless framework sites rank well. "Google renders JavaScript perfectly, so it's solved" is also false — rendering ability does nothing about links with no href, content gated behind interactions Googlebot won't perform, or hash-fragment URLs that collapse a site into one page; those are architecture failures a flawless renderer still can't overcome. The accurate middle position: Google can render JavaScript, but rendering is a separate step that can be delayed or fail, and JavaScript sites still routinely lose traffic to avoidable architecture mistakes — so use frameworks freely, but control the rendering mode (prefer content in the HTML) and verify what Google sees.

Exercise 19.29 †

Two honest questions before adopting a bot-snapshot "prerender for SEO" service: (1) "Is the snapshot served to bots substantively identical to what users see?" — if not, it is cloaking, a policy violation; and even if identical, drift between the two versions over time is the classic failure mode. (2) "What happens when the snapshot service is slow, down, or serving a stale version — and how would we detect it?" — you are inserting a third-party dependency between Google and your content. Google's stance on this general approach (dynamic rendering): it is a workaround, not a recommended long-term solution; Google steers teams to server-side rendering, static generation, or hydration instead. So the service may work, but you should treat it as a stopgap and plan to server-render.

Exercise 19.31 †

A plain-language checklist for whoever maintains rivertownhome.example: 1. Look at the "real" page. Open the page, right-click, choose "View Page Source." Use Ctrl+F to search for a sentence you can see on the screen. If you find it, the page is fine — stop here. 2. Ask Google directly. If you didn't find the sentence, copy it, put quotation marks around it, and search Google for it (add site:rivertownhome.example after it). If our page shows up, Google has the text — probably fine. 3. Check what Google saw. If Google didn't show the page, open Search Console, paste the page's address into the inspection box at the top, and look at the rendered version. If our words are missing there, that content is hidden from Google. 4. Decide. Content that's in "View Source" needs nothing. Content that only shows up in the browser (like the star-rating widget) isn't really visible to Google — flag it, and don't count on it to help us rank. (No jargon: no "SSR," no "DOM," no "hydration" — just "the real page," "ask Google," "check what Google saw," "decide.")

Exercise 20.1

International SEO is the practice of structuring and optimizing a site so search engines show the right language version and the right country version of its content to each searcher, and so each version can rank in its intended market. The two independent axes are language (serve Spanish to Spanish speakers regardless of country) and country (serve a country-specific experience — currency, shipping, law — possibly in the same language). A site that needs one but not the other: a U.S. company with many Spanish-speaking local customers needs the language axis (an English and a Spanish version, same country) but not the country axis; conversely, a store selling to both the U.S. and U.K. in English needs the country axis (dollars vs. pounds) but not a second language.

Exercise 20.3 †

The return-tag rule: every version in an hreflang set must reference every other version and itself, and every reference must be returned by the page it points to — if page A names page B as its alternate, page B must name A back. A missing return tag means Google may discard that pairing. This is why hreflang cannot be verified one page at a time: correctness does not live in any single page but in the relationships between pages. A page can carry a perfectly well-formed hreflang block and still be broken because the page it points to fails to point back. To validate, you must crawl the whole set and cross-check that every reference is reciprocated — an inspection of one page in isolation can never prove the set is sound.

Exercise 20.5

Translation converts the words from one language to another. Localization adapts the whole experience to a locale — language plus currency, units, date formats, imagery, examples, idiom, tone, legal/regulatory detail, payment methods, and the actual terms local people search. A concrete example that translation leaves alone but localization changes: prices and currency — a translated U.K. page might still show U.S. dollars and U.S. sizing, while a localized one shows pounds, U.K. sizes, U.K. spelling ("colour"), and the local word ("trainers," not "sneakers"). Translation changes the sentence; localization changes the whole page around the market's reality.

Exercise 20.7

Recommend a subdirectory (example.com/de/, example.com/fr/, etc.). The justification is authority consolidation (Chapter 22): the company is expanding by language only, within a single country of operation, so there is no need for a country-specific domain and no reason to split hard-won authority. A subdirectory keeps every language version on the one domain, so each new version draws on the whole site's accumulated authority from day one, and the company maintains a single domain, certificate, and setup. A ccTLD would force each language onto a separate domain that must earn authority from zero (wasteful and slow here), and a subdomain would introduce separation with no offsetting benefit. The decision is about where the authority sits, and the answer is "all in one pot" — not a folklore claim that subfolders are secretly favored.

Exercise 20.8 †

A ccTLD encodes a country, not a language, in the domain itself: example.de says "Germany," full stop — it cannot, by the domain alone, distinguish which language a German visitor prefers. This bites in any officially multilingual country. Canada is the cleanest real example: example.ca targets Canada, but Canada has two official languages (English and French), and the .ca domain cannot tell Google whether a given page is for English-Canadian or French-Canadian searchers. (Switzerland, with German, French, and Italian, and Belgium, with Dutch and French, are others.) That limitation — a domain can speak to country or nothing about language — is a large part of why hreflang, which can carry language and region together (en-ca, fr-ca), exists at all.

Exercise 20.9

Can: hreflang gets the correct existing language/region version of your page shown to the right searcher — the British visitor gets the pounds page, the Mexican visitor the Spanish one — reducing the wrong-version mismatch that sends people bouncing back to the SERP. Cannot: it does not make you rank where you otherwise wouldn't; it only swaps among your own alternates once one is already competing, and it cannot rescue thin or badly-localized content. Honest rewrite of "We'll add hreflang and start ranking in Germany": "We'll add hreflang so that once our German page is competitive, Google shows it — not our English page — to German searchers. Actually ranking in Germany still depends on a genuinely localized page and German-market relevance, quality, and links; hreflang routes, it doesn't rank."

Exercise 20.11

Honest answer: you don't — that setting no longer exists. Google retired the International Targeting report (which held the manual country-target control for generic-domain sites), with the change rolling out in 2022. What changed: Google removed the manual override on the reasoning that the setting was little used and that it could now infer the relevant country well enough from other signals. So country targeting for a gTLD site is now a consequence of hreflang, on-page and business signals (local currency, address, phone), and links from within the country — not a switch you toggle. Anyone still telling you to "set your country in the International Targeting report" is quoting advice that outlived its tool (Case Study 1).

Exercise 20.13 †

This is the canonical conflict, the deadliest hreflang failure. Two signals contradict: the German page's hreflang says "I am a distinct German version, show me to German users," while its canonical tag says "I am a duplicate of the English page — index that one instead." Google generally honors the canonical, so it treats the German page as a duplicate and drops it from the index; that is why it "vanished." Fix: make the German page's canonical self-referential — it must point to itself (example.com/de/page canonicals to example.com/de/page), not to the English version. In an hreflang set, hreflang points across versions and each version's canonical points at itself; never cross them. (Usually the culprit is a plugin/CMS configured to canonicalize everything to the "main" language — check that setting.)

Exercise 20.15 †

• en-uk — invalid: the ISO 3166-1 region code for the United Kingdom is GB, not UK. Corrected: en-gb.
• es_ES (underscore) — invalid separator: hreflang joins language and region with a hyphen, not an underscore. Corrected: es-es (case doesn't matter to Google, but the hyphen does).
• hreflang="German" — invalid: the value must be an ISO 639-1 language code, not a language name. Corrected: de (or de-de, de-at, de-ch if you are targeting a specific German-speaking region).

Each invalid value is simply ignored by Google, silently disabling that annotation — the page looks fine but the targeting doesn't work.

Exercise 20.17

The failure is a language mismatch: the page is annotated as French-Canadian (fr-ca) but its actual body content is in English. hreflang is a confirmatory signal — Google can read the page's real language and see that it contradicts the annotation. When the declared language and the on-page language disagree, Google may distrust or ignore the annotation, because the whole point of hreflang is to route users to a page in the language they want, and this page would deliver English to someone promised French. The fix: make the annotation honest — either tag the page as the language it is genuinely written in, or (if it is meant to be French-Canadian) actually produce the French content. Never label a page a language it is not.

Exercise 20.19 †

(Guided — answers vary by the site you pick.) The skill being checked is reading an hreflang set for completeness. Example deliverable for a global retailer's page: "(a) it lists 14 language/region versions; (b) yes, it includes an x-default pointing to the global .com selector; (c) yes, the page references itself — I can see its own URL with its own hreflang value in the block. The set looks complete from this one page, but I can't confirm the return tags are reciprocated without crawling the others." The key insight to record: inspecting one page can show self-reference and the presence of an x-default, but it cannot confirm the return-tag rule — that requires checking the pages it points to.

Exercise 20.21

(Guided — answers vary by site/access.) The deliverable is a per-country landing check. Example: "In Search Console → Performance, with a Country filter, traffic from the United Kingdom is landing overwhelmingly on /uk/ URLs (good — the routing is working), but a noticeable slice of German-country impressions are landing on the English /us/ page rather than /de/ — a sign the German hreflang isn't being honored for those queries, worth a crawl to check the return tags and canonical." The skill: using the country filter to observe whether targeting actually works in the field, rather than assuming the annotations are being honored. If you have no access, the correct note is that Search Console setup is the Chapter 27 task, with a date to do it.

Exercise 20.23 †

Fix the canonical conflict first — "all fr-fr pages canonical to their en-us equivalent." That single misconfiguration is telling Google every French page is a duplicate of its English counterpart, which drops the entire French locale from the index; nothing else you fix matters while those pages can't be indexed at all. It is also likely a one-setting fix (the plugin/CMS canonical rule), so it is the biggest recovery for the least effort. Second, fix the missing self-references (all 20 fr-fr pages) and the missing return tags (14 URLs) so the reciprocal set is complete — probably the same root cause as the canonical issue (a misconfigured internationalization plugin). Fix the non-200 hreflang URLs (repoint them to the final, canonical 200 OK URLs) as cleanup. Then re-crawl to confirm before waiting on Google to re-process.

Exercise 20.25 †

Three bundled falsehoods: 1. "Translate into 20 languages with our one-click AI tool" — raw, unreviewed machine translation is discouraged by Google and reads as low-value to native speakers; it also skips the local keyword research that makes a page relevant. Truth: real localization (human review, local terms, local context) is what earns rankings — machine output is at best a first draft. 2. "Rank worldwide overnight" — hreflang and translation do not make you rank in new markets, and nothing ranks "overnight"; ranking in each market is earned the ordinary way (relevance, quality, authority, local links). Truth: hreflang routes the right version to the right user; the winning is earned per market, and SEO is a long game. 3. "hreflang prevents any duplicate-content penalty" — there is no duplicate-content penalty to prevent (duplicates are filtered, not penalized), and different languages aren't duplicates at all. Truth: the only real concern is same-language regional variants, and the remedy is hreflang + self-referential canonicals + genuine localization — not protection from an imaginary penalty.

Exercise 20.27

Beyond SEO, launching machine-translated sites in eight unsupportable languages creates real business and ethical problems. Business: you generate inquiries, orders, or leads you cannot fulfill — support tickets in languages no one on staff reads, orders you cannot ship, promises the site implies you cannot keep — which produces refunds, bad reviews, and churn that costs more than the phantom "growth" is worth; and the thin translated pages can drag down the quality signal of the core market that actually pays the bills (Case Study 2). Ethical: presenting a polished, localized-looking storefront to customers you have no ability to serve is a form of misrepresentation — you are inviting people to transact on an implied promise (of service, language support, delivery) you know you cannot honor. "Looking bigger" by faking a global presence is a trust violation, not a growth strategy. The honest move is to serve the markets you can serve well and expand only when you can staff the far side of the effort.

Exercise 20.29 †

Honest answer to Marisa and Tony: "No — Rivertown should not buy ccTLDs or launch country sites. The one fact that settles it is that every Rivertown customer has to be reachable by one of our trucks, and our trucks serve this one metro. There is no customer in another country we could actually serve even if we ranked there, so there is nothing for the international machinery — ccTLDs, geotargeting, cross-country hreflang — to target. Buying country domains would split our already-small authority across separate sites, add fragile technical setup we'd maintain badly, and generate inquiries we can't fulfill. The place to grow is the local pack in our five cities (Chapter 25), not other countries." (If they press on the Spanish-speaking-callers point, that is the language exception in Exercise 20.30 — a /es/ subdirectory, not international expansion.)

Exercise 21.1

The five kinds of migration: (1) Domain change — oldbrand.com → newbrand.com (a rebrand or a new ccTLD). (2) HTTP→HTTPS — turning on encryption so every URL becomes https://. (3) CMS/platform change — e.g., WordPress → a custom build, or a custom build → Shopify. (4) Redesign — same domain and URLs, new templates/design/content structure (Rivertown's theme change). (5) Consolidation/restructure — merging several sites into one, splitting one into several, or reorganizing a single site's URL structure.

Exercise 21.3

A URL inventory is the complete, de-duplicated list of every current URL that matters, annotated so each gets a deliberate migration decision. Four sources and what each uniquely adds: (1) A crawler (Screaming Frog) — finds every internally linked URL (but only those). (2) Search Console Performance report — every URL that earned an impression/click, ranked by value, so you see the crown jewels. (3) Analytics (GA4) — every URL that got a visit, including orphans and old landing pages a crawl misses. (4) A backlink tool — every URL with external links pointing at it, the pages whose lost redirects would sever off-site authority. (Also valid: XML sitemaps, and server logs for what Googlebot actually requests.) The point of combining them is that no single source knows every URL — especially the orphaned, link-bearing pages.

Exercise 21.4 †

A 301 redirect is a permanent server instruction (an HTTP status code) that a URL has moved permanently to a new address; the browser and crawler are forwarded automatically. The two properties that make it right for a migration: (1) it is permanent, so Google updates its index to the new URL and stops expecting the old one; and (2) it passes the old URL's ranking signals — links, authority, history — to the new one, which is how a well-executed migration keeps its rankings. Contrast the 302 (temporary): it tells Google to keep indexing the old URL because the content will return, so using a 302 for a permanent move stalls signal consolidation and sends a contradictory message.

Exercise 21.5

A redirect chain is a URL that redirects to a URL that itself redirects, instead of going straight to the final destination.

CHAIN (bad):  /page  ─301▶  /https-page  ─301▶  /new-domain-page  ─301▶  /final-page
CLEAN (good): /page  ─────────────────301─────────────────────────▶  /final-page

Each hop in the chain adds latency, wastes crawl budget, and risks a dropped/diluted signal; engines abandon a long chain after a limited number of hops. Fix: redirect the original URL directly to the final URL, and update old rules to skip the middlemen.

Exercise 21.7

Risk in a migration is about how much judgment the change requires, not how much changes. An HTTP→HTTPS move changes every URL, but the mapping is perfectly mechanical — every http://X maps to https://X, one to one, with zero decisions to get wrong — so as long as the redirects and canonicals are done, there is little to misjudge. A redesign changes no URLs, but it can silently delete content Google was ranking, drop internal links, ship a staging noindex, or regress speed — failures that are invisible until traffic falls and that each require human judgment to prevent. Much changing + no judgment = low risk; nothing changing + hidden judgment calls = higher risk.

Exercise 21.9 †

Google treats a redirect from a specific old page to the homepage as a soft 404 because the homepage is not the equivalent of the old page — its content and intent are different, so Google concludes the original page is effectively gone rather than moved. What is lost: all of the old URL's ranking signals — the backlinks, the authority, the history that made it rank — because a soft-404'd redirect passes nothing. This is worse than doing nothing (leaving a clean 404) because it looks like a save to any human who clicks and lands "somewhere," so the team believes the equity was preserved when in fact it was destroyed, page by page — and they stop looking for the real fix (mapping to the equivalent).

Exercise 21.11

If a migrated site relies on redirects for its internal navigation, every internal click fires through an unnecessary redirect hop. That adds latency for users, wastes crawl budget (Googlebot follows a redirect on every internal link instead of hitting the final URL), scatters redirect load across the whole architecture, and signals sloppiness. Redirects are meant to be the safety net for external links and bookmarks — the ones you don't control. Your own links you do control, so the new templates and body content should point directly at the final new URLs from launch day; let redirects handle only the outside world (a direct application of Ch 15's internal-linking discipline).

Exercise 21.13

Two separate reasons: (1) The day — launching Friday before a long weekend means the inevitable volatility hits when the fewest engineers are around to catch and fix problems; a shipped noindex or a 404 flood can compound for three unwatched days. Launch in a low-traffic weeknight window when the team is available. (2) The season — launching right before your biggest sale means even a normal, fully-recoverable dip lands during your highest-stakes weeks; a 20% dip that recovers in five weeks is fine in a quiet month and a disaster across your peak. Never migrate before peak season (a retailer doesn't replatform in November).

Exercise 21.15 †

Cause: the staging noindex / robots block shipped to production — the live site is telling Google not to index it, so the whole site is falling out of the index (hence "Excluded by noindex" climbing across the site and traffic going to zero, not merely dipping). This is the §21.5 catastrophe (first named in Ch 1 §1.4). Act today — immediately. It is not "wait and see": every hour the block stays live, more of the site drops out. Load a live production page and inspect a URL in Search Console to confirm, then remove the noindex/Disallow from every template and verify on the live site, resubmit the sitemap, and request indexing for the crown jewels.

Exercise 21.16 †

Cause: this is the normal migration curve — Google reprocessing a large, clean change (re-crawling old URLs, following redirects, re-indexing new URLs, reconsolidating signals). A ~15% dip in the first weeks with rankings wobbling ± a few positions and the dip flattening rather than deepening is exactly what a healthy domain move looks like. Wait and monitor. Do not roll it back (that forces a second reprocessing and doubles the volatility). Keep watching the trend: a flattening dip with wobbling-not-gone rankings is recovery beginning; continue the monitoring cadence and check the calendar for any concurrent core update.

Exercise 21.17

Cause: missing redirects for a batch of old blog URLs — likely orphaned pages the navigation-based mapping missed (the §21.2 inventory gap), now returning 404. Act — but it's a targeted fix, not a full-site emergency. The rest of the site indexing normally tells you the core migration is healthy; the 60 404s are a real, cheap-to-fix leak. Go back to the inventory (Search Console Performance, analytics, backlink data), find every old blog URL, map each to its equivalent, add the 301s today, and assume more are hiding among URLs Google hasn't re-crawled yet — re-audit rather than fixing only the 60 currently showing.

Exercise 21.19

After a same-URL redesign with no 404s and full indexing, two redesign-specific causes the chapter warns about: (1) Silently dropped on-page content or elements — the new templates deleted body copy, headings, or internal links Google was ranking the pages on. Confirm by comparing the new pages against the baseline/old versions (or an archive) for lost text, and crawl the new site for missing internal links and changed titles/H1s. (2) A regressed page experience — the new design is slower or worse on mobile (Ch 16/17). Confirm with PageSpeed Insights field data and the Search Console Core Web Vitals report versus the pre-launch baseline. (Also fair: lost structured data reducing rich-result eligibility — check the Rich Results Test.)

Exercise 21.21 †

(Guided — answers vary by site.) The deliverable is a real ranked inventory: the top-20 pages by 12-month clicks from Search Console's Performance report, with average position for the top 5. The skill being checked is recognizing that value is uneven and specific — a handful of pages usually do most of the work — and being able to name the single URL you could least afford to lose and why (e.g., "the /water-heater-replacement guide — it's our top organic entry point and carries most of our earned links, so a broken redirect there would cost both traffic and off-site authority"). A learner who names a page for a defensible reason (traffic + links + conversions), not just raw traffic, has understood §21.2.

Exercise 21.23

(Guided.) The deliverable is three URL Inspection results, each recording Is the URL on Google? and the Google-selected canonical. The point is to build the reflex before launch day: this 40-second check, run on crown-jewel URLs the morning after any launch, is the fastest way to catch a page that has silently fallen out of the index or had its canonical flipped. A good answer also notes what each result means — "on Google, canonical matches the URL" = healthy; "not on Google" or "canonical is a different URL" = investigate now.

Exercise 21.25 †

Every row is wrong: - /services/drain-cleaning → / (301): lazy homepage redirect — Google treats it as a soft 404 and passes no signals. Fix: map to the equivalent new page, e.g., /plumbing/drain-cleaning. - /blog/2020-winter-tips → /blog/2022-winter-tips (302): a temporary code for a permanent move; signals won't consolidate. Fix: make it a 301. - /ac-repair-northgate → /cooling/ac-repair (301): the redirect drops the city — a service×city page redirected to a generic service page loses the local intent and relevance. Fix: map to the equivalent service×city page, e.g., /cooling/ac-repair-northgate (or the nearest local equivalent). - /old-quote-form → /new-quote-form (301, but target 404s): a broken redirect — the destination doesn't exist, so users/crawlers hit a 404 at the end. Fix: correct the target to a URL that actually returns 200, and re-test.

Exercise 21.27

Two false/unsupportable claims. (1) "Guarantees zero traffic loss" — no honest practitioner promises this; Google itself says to expect temporary fluctuations while it reprocesses, so even textbook migrations usually dip. Honest version: "we protect the equity and minimize and recover from the dip." (2) "Your rankings will not drop at all" — a specific promise about Google's behavior that no one controls (rankings depend on reprocessing and on competitors). Honest version: "expect a temporary wobble; we monitor closely and expect recovery over weeks, and we'll know within days if anything is actually broken." The tell in both: certainty about an outcome that is Google's to decide.

Exercise 21.29 †

Honest recommendation: do not migrate the whole site to a new domain this week. A domain change is the highest-risk migration; done with no inventory, no redirect map, and two weeks before peak season, it is very likely to cost significant traffic and revenue during the most valuable weeks of the year — the worst possible time for even a normal dip. What I would refuse: launching a domain move without a complete inventory, a tested one-to-one redirect map, and a go-live checklist, because that's not a migration, it's a gamble with the client's revenue. The alternative that respects the urgency: decouple the brand launch from the domain move. Launch the rebrand's messaging, logo, and campaign now on the existing domain (rebrands don't require a new domain to go live), and schedule the domain migration for after peak season, done properly — inventory, map, staged launch, monitoring. The client gets their timely rebrand; the traffic stays protected.

Exercise 21.31

The two risks that kill a same-domain theme redesign: (1) The silent element drop — a new theme regenerates every template and can quietly discard the title tags, heading structure, internal links, structured data, and alt text that earlier chapters' SEO work built. (2) The staging noindex shipping to production — the theme is built on a blocked staging site, and if that block ships at go-live the whole site falls out of the index. The single starred checklist item that prevents the worse of the two: at launch, remove the staging noindex/robots block and verify on the live site that the site is indexable (by loading a production page and inspecting a live URL in Search Console) — not merely intending to, but verifying, per template.

Exercise 22.1

A backlink is any single inbound link from another site to a page on yours; a referring domain is a unique website that links to you, counted once no matter how many backlinks it sends. "40,000 backlinks" is weaker than "300 referring domains" because raw backlink counts are inflated by many links from the same few sites (site-wide footers, a spammy directory that links you 10,000 times); referring domains measures how many distinct sites vouch for you, which is what authority actually depends on. The honest boast is almost always the smaller number.

Exercise 22.2 †

PageRank treats each link as a vote for the page it points to — a signal of importance that lives on other people's sites and so can't be faked from your own. The second half: votes are weighted by the voter. A link from a page that is itself important (heavily linked-to) counts for far more than a link from an obscure page, and importance is defined recursively (important pages are ones important pages link to). So PageRank estimates a page's importance from both the quantity and the quality of the pages linking to it.

Exercise 22.3

$C(T_i)$ is the number of outbound links on linking page $T_i$. Dividing that page's PageRank by $C(T_i)$ models the idea that a page splits its single vote among everything it links to: if it links to 3 pages, each gets a third of its authority; if it links to 300, each gets a three-hundredth. It captures why a link from a selective page is a concentrated endorsement and a link from a page that links to everything is diluted almost to nothing.

Exercise 22.5

The four situations: (1) an ordinary follow link (no attribute) — a full editorial endorsement that can pass authority; (2) nofollow — "I link to this but don't treat it as my endorsement / don't pass authority"; (3) sponsored — this is a paid, advertising, or affiliate link; (4) ugc — this link is user-generated content (a comment or forum post), not something the site owner placed.

Exercise 22.6 †

An editorial link is one a publisher freely chose to give because your content earned it — no payment, no exchange, no manipulative request. It is durably safe because it is exactly the kind of independent, genuine citation PageRank was built to count; Google's whole link-quality effort is an attempt to keep counting these. A self-placed link (a directory submission, a forum signature, a blog comment) or an acquired link (paid or bartered) is one you caused to exist rather than one you earned; those carry little or no value and, done at scale or against the rules, become a liability.

Exercise 22.7

The damping factor ($d$, conventionally ~0.85) is the probability, in the "random surfer" story, that the imaginary surfer clicks another link on the current page rather than jumping to a random page. It represents a web user who mostly follows links but occasionally (about 15% of the time, the $1-d$ term) gets bored and teleports somewhere random. Practically, it keeps the math stable and stops a closed cluster of pages that only link to each other from hoarding all the importance.

Exercise 22.9 †

The modest page that links out to only 3 pages passes more authority per link, because each of its outbound links receives a larger share of its authority (roughly a third) than each of the high-PageRank page's 200 links (roughly a two-hundredth). This is the $C(T_i)$-division intuition. The factor this comparison ignores is the absolute authority of each linking page: if the 200-outbound page is vastly more authoritative, its diluted share might still exceed the modest page's concentrated share — and relevance and placement could flip the decision again. The lesson is that "few outbound links" is one factor, not the whole grade.

Exercise 22.11 †

Two links to an HVAC company: (A) a link from a very high-authority but topically unrelated site — say, a general celebrity-gossip site with enormous traffic; (B) a link from the regional home-and-garden publication or the state HVAC contractors' association — lower raw authority, but squarely relevant. Link B is usually the better link because relevance is itself a credibility signal: a vote from within your topic is a more meaningful endorsement of your expertise, it matches how Google builds topical authority (Ch 4), and a burst of high-authority irrelevant links is a classic manipulation fingerprint. Authority is not the only axis; a relevant vote from a real neighbor beats a loud vote from a stranger.

Exercise 22.13

Google moved nofollow from a directive to a hint (2020) because a strict "ignore entirely" rule threw away useful information: a widely-cited source that everyone happens to nofollow is still obviously an important source, and Google wants to understand the web fully. Treating the attribute as a strong suggestion lets Google keep the information while still respecting the "not an endorsement" signal. The publisher's advice barely changes because you still use the attributes honestly to label paid/UGC/unvouched links; you were never supposed to rely on nofollow as a precise on/off switch for authority, and now even less so.

Exercise 22.15

Grain of truth: the public Toolbar PageRank score — the green 0-to-10 bar — is genuinely gone (updates stopped ~2013; removed 2016), so you can no longer read a Google-blessed PageRank number. Falsehood: that Google stopped using links or the PageRank concept. Google engineers have publicly confirmed a form of PageRank is still used internally among many signals. Accurate restatement: "The visible PageRank score is dead; PageRank the signal is not — links still carry authority, you just can't see a tidy number for it."

Exercise 22.16 †

The remaining lever is external authority — genuine links from other websites into Rivertown's site. Chapters 3 and 9 fixed intent and on-page; Chapter 15 fixed internal linking, which distributes authority but cannot manufacture it. If the whole site has thin external authority, routing a small amount of it to the water-heater page still leaves it under-powered against a competitor "referenced by local news and home-improvement sites." The chapters that supply the lever are 23 (earning links) and 24 (link tactics). The #11 page's last mile is an authority problem.

Exercise 22.17

Most likely: a bought or spammed link scheme (the ~400 unrelated overseas links with identical commercial anchors are the fingerprints from §22.6 — velocity spike, irrelevance, anchor over-optimization). The rise came first because forged links can lift rankings until they are reassessed; the collapse came later because detection is retroactive — a spam-system refresh, a Penguin-style reassessment, or a manual review caught up with the scheme months after it "worked," and Google devalued the links or applied a manual action. The gap between rise and fall is the delayed fuse, not evidence the tactic was safe.

Exercise 22.19

Three red flags in "add your link to twelve old posts for \$50 each, all with the exact anchor you want to rank for": (1) it's paid to pass ranking value — a link scheme under Google's policy (a paid link must be sponsored/nofollowed, which would defeat the buyer's purpose); (2) exact-match commercial anchor text repeated across all twelve links — the anchor over-optimization fingerprint from §22.3/§22.6; (3) self-serving placement into old, unrelated posts — not an editorial link earned by the content, just inserted for money. Any one is disqualifying; together they're a textbook manipulation offer.

Exercise 22.21 †

(Guided — numbers vary by site.) The deliverable is three recorded numbers plus one interpretive sentence each. Example: "Total external links ~4,100, but only ~120 referring domains — the gap suggests a few sites link me many times (check for site-wide footer links or a spammy directory)." "Top linking sites are mostly real and relevant — healthy." Or: "Top anchor text is a repeated exact commercial phrase, not my brand — suspicious, worth investigating." The point is to name each number as a symptom (healthy / thin / suspicious) without acting; this is the first pass of a link audit and the seed of your Strategy File baseline.

Exercise 22.23

(Guided.) Your most-linked page should usually be your homepage or a flagship resource, because that is what people naturally cite. If a trivial page (an old promo, a stray PDF, a login) is your most-linked, it can mean: an accidental viral link, a scraped/embedded asset, or — less happily — a spammy pattern pointing at an odd URL. It also matters for authority flow (§22.5): whatever page receives your external authority should be well-connected internally (Ch 15) so that authority can reach the pages you actually want to rank. Investigate why the trivial page leads, and make sure your real priority pages are internally linked from wherever the authority lands.

Exercise 22.25 †

Opportunity B (the newspaper columnist) is the better link, despite its lower DR (48 vs. 55). It differs on at least three §22.3 dimensions: relevance (home-improvement content vs. a generic "business tips" site), placement (an in-content link vs. an author-bio link on a page that publishes six sponsored posts a day), and editorial intent (the writer chose to link and picked the anchor vs. a paid slot with a buyer-chosen exact-match anchor). The higher DR doesn't settle it because DR is a third-party estimate of link-based ability, easily inflated, and a site publishing six sponsored posts daily is exactly the low-editorial-standard, footprint-heavy source §22.6 warns about. A relevant, editorial, in-content link beats a higher-metric sponsored bio link.

Exercise 22.27 †

The myth is that Domain Authority is a Google ranking factor you can "raise" to reach page one. DA is a third-party 0–100 score from Moz that predicts ranking ability from link data; Google does not use it (Google's own people say there is no single domain-authority score in ranking). So promising to "raise DA from 22 to 40" is promising to move a vendor's estimate, not your Google rankings. The risky behavior it encourages: because DA is link-driven, chasing the number pushes consultants toward acquiring links in bulk — i.e., the link buying/spam of §22.6 — which optimizes the thermometer by holding a match under it and can create a real liability.

Exercise 22.29

(1) Mechanism: buying links forges the independent editorial votes PageRank depends on, so it corrupts the very signal that gives links value. (2) Detectability: \$500-for-100-links leaves fingerprints — unnatural velocity, network footprints, irrelevant sources, over-optimized anchors — that Google's spam systems and manual reviewers are built to spot. (3) Remedies: Google either devalues the links (your money is wasted) or applies a manual action (your rankings crater). (4) Retroactive risk: even if it "works" now, reassessment can undo it months later, so you'd be building the business on a delayed liability — no honest practitioner can call that safe. Decline it; earn links instead (Ch 23–24).

Exercise 22.31 †

A two-column baseline for Rivertown:

Legitimate (keep/build on): branded/navigational links (its own social profiles, a few natural customer/blogger mentions); local citations (chamber of commerce, supplier "find a dealer" page, standard business directories — many nofollow but valuable for local trust, and a Chapter 25 topic); one genuine editorial link (the regional paper's story on Rivertown sponsoring a youth sports team).

Inherited liability (flag, decide in Ch 26): (a) low-quality directory/article-spin links from the old contractor — fingerprint: bulk low-value, footprint; (b) overseas "guest post" links on unrelated sites with the anchor "best HVAC repair Rivertown" — fingerprints: irrelevance + exact-match anchor over-optimization; (c) blog-comment and forum-signature links across irrelevant sites — fingerprint: self-placed, irrelevant, automated pattern. Record the counts and anchor profile; do not disavow yet — that decision is Chapter 26's.

Exercise 22.33

(Guided — deliverable, not a fixed answer.) A one-page baseline from Search Console: your referring-domain count; a split of your top linking sites into legitimate/relevant, legitimate/irrelevant, and questionable; and your top anchor text. The required single sentence connects the baseline to your rankings, e.g.: "With only ~30 relevant referring domains and a mostly-branded anchor profile, my priority service page lacks the external authority its competitors have, which — more than any on-page issue — is why it sits on page two." Disavow nothing; this baseline is what your Chapter 23–24 earning plan and any Chapter 26 disavow decision will build on.

Exercise 23.1

Link earning is acquiring links as the natural byproduct of publishing something others independently choose to reference; link building starts from a link target and reverse-engineers activities (asking, trading, buying) to hit it. Completion: "Only earned links compound because the asset itself deserves them, so they keep arriving with no further input — whereas built links stop the moment the asking or paying stops (and may be devalued)."

Exercise 23.3 †

Digital PR earns links and mentions from journalists and publications by giving them something newsworthy, usually original data or expert commentary. Newsjacking is a time-sensitive form of it: inserting your expertise or data into a breaking story while it is still developing. What newsjacking adds is timing — it exploits a short window when a story is hot and reporters are actively hunting for sources, so speed matters as much as substance.

Exercise 23.5

Outreach is contacting a relevant person to make them aware of a genuinely useful asset you've published. The three qualifiers that separate it from spam: it goes to a relevant person (not a bought list), it offers something that genuinely helps (not a bare ask), and it is framed around their audience's benefit (not yours). Ignore any of the three and it's spam.

Exercise 23.7 †

A citation obligation is the situation where, to use a fact in their own writing, a person must credit its source. Original data creates one because if you are the only one who measured "furnace replacement in the metro costs X–Y," anyone who wants to state that figure has to attribute it to you — and attribution online is usually a link. A how-to guide usually doesn't create the obligation because its advice is available on many sites and can simply be paraphrased; there's no unique fact that must be credited to you.

Exercise 23.9

The calculator (b) is the better linkable asset. Reuse: a tool answers a recurring question over and over, so people bookmark it and return — utility that gets used repeatedly gets referenced repeatedly, whereas a tips post is read once. Citation: other sites point their readers to a genuinely useful tool ("use this calculator to size your furnace") far more readily than to generic advice they could restate themselves. Tips can earn traffic; a good tool earns links.

Exercise 23.11

Because digital PR pitches a story, and the asset — usually original data — is the story. Pitch a reporter with no asset and you're offering "please link to our website," which is not news and gets deleted. The engine of successful digital PR is a linkable asset (§23.2). §23.2 must come before §23.3 because without something worth citing, the outreach in §23.3 has nothing to offer — it's noise, not a service to the journalist.

Exercise 23.10 †

The newsjacking window is the short span — hours to a couple of days — during which a story is breaking and reporters are actively looking for sources and quotes. Before the news breaks there's no story to join; after it's filed, your pitch is late and useless. A rough, genuinely useful quote sent inside the window beats a polished pitch sent two days later because the reporter's need is now: on deadline, a usable answer that arrives in time is worth infinitely more than a perfect one that arrives after the article is published.

Exercise 23.13

A referring domain counts each unique linking website once; raw backlink count counts every individual link. If one site links you 100 times (say, a site-wide footer link on every page), the backlink count reads 100 but it represents roughly one vote — one referring domain. Referring domains measure how many distinct sites vouch for you, which is what authority actually reflects; backlink count is easily inflated and misleads.

Exercise 23.14 †

Over a year, earned-link growth is typically lumpy: long flat stretches where little happens, punctuated by steps when a real asset lands and gets cited, followed by slow secondary accrual as new writers discover the now-established resource. Knowing this shape helps a strategist hold their nerve through the flat months — which are most of the timeline — instead of concluding "it isn't working" and quitting right before a step. Expecting a smooth diagonal is what makes people abandon link earning prematurely.

Exercise 23.15 †

Most likely reason: the guide is good but not markedly better than what already ranks — comprehensive length without a genuine reason to cite it (no original data, no unique tool, nothing that creates a citation obligation). Before concluding "guides don't earn links," check: (1) does it contain anything a writer would have to reference (a stat, a framework, a visual) or is it a thorough restatement? (2) has anyone with a relevant audience even been told it exists (§23.5)? A definitive-seeming guide that's really a rehash, unpromoted, is the common — and fixable — cause.

Exercise 23.17 †

No, it's not a success. The strategy-level failure: the team treated outreach as a numbers game (600 emails) rather than earning — so the only links available were paid ones, which are link schemes under Google's guidelines (a liability, not an asset). The real problem isn't the email copy; it's that there was apparently no linkable asset worth citing behind the campaign, so the only responders were people selling placements. Fix the strategy: build something worth citing (§23.2), then do low-volume relevant outreach — don't scale the asking.

Exercise 23.19

Better first move: instead of asking bloggers for links, find the writers and sites already covering the topic the tool solves and make sure the tool is genuinely discoverable and useful to them — earn the reference by being the obvious resource. Concretely: ensure the tool is indexable and linked from relevant pages on your own site (internal links, Ch.15), pitch it as a resource to the handful of writers whose readers would use it (framed around their readers' benefit), and consider a small piece of original data the tool generates as a story hook (§23.3). The asset already deserves links; reduce the friction to being found rather than mass-asking.

Exercise 23.20 †

(Guided — answers vary by site.) The deliverable is one sentence identifying your most-linked page, its type, and the implication. Example: "Our single most-linked page is a free 'load-size calculator' (~40 links) — a tool, which tells us our niche links to utility, so we should build one more genuinely useful tool this year rather than more blog posts." If the report is empty, the finding is: "We have earned essentially no links, which means we have never published a deliberate linkable asset — that's the gap this chapter fixes; name one asset to build (Ex. 23.22)."

Exercise 23.21

(Guided.) The deliverable is a recorded baseline: today's total linking sites from GSC (a rough referring-domain count) and the date, plus a 90-day reminder. There is no single right number — the value is establishing the trend line so you can later judge, honestly, whether link earning is working. Note the two caveats: GSC's link data is approximate and updates slowly.

Exercise 23.23

(Guided.) The deliverable identifies a competitor's most-referenced page, its asset type, and whether you can beat or localize it. Example: "Competitor X's most-linked page is a national 'cost of HVAC repair' guide; that's an original-data/definitive-guide asset. We can't out-scale their national reach, but we can own the local version — real metro cost data by city — which they don't have. That's a winnable angle (exactly Rivertown's play)." The point is to spot the asset type your niche rewards, then find a version you can genuinely win.

Exercise 23.24 †

Rewritten (illustrative): "Hi Priya — I read your Gazette piece on winter utility bills; you cited the state heating-cost average. We just published local numbers: furnace repair and replacement costs across all five metro cities, from 1,200 of our own completed jobs, with the methodology. The Cedar Hills figure surprised us. Data's here if it's useful for a follow-up: [link]. No ask — just thought it might fit your beat." Three things added: (1) a specific reference to a real article the recipient wrote; (2) something of genuine value to their beat (local data they can't get elsewhere); (3) a real name/context and an easy, low-pressure link. One thing removed: the bare "would you add a link?" ask — replaced by simply informing a good writer, who will do the obvious if the asset is worth it.

Exercise 23.25

Improved answer (illustrative): "Below freezing, a heat pump has to pull warmth from very cold outside air, so it works harder and delivers less — many older units drop off sharply and the backup electric or gas heat kicks in, which is why bills spike on the coldest days. Modern cold-climate models hold up much better, but homeowners should expect reduced efficiency in a hard freeze, not a failure. — Tony Delgado, licensed HVAC technician (14 yrs), Rivertown Home Services. Happy to expand or send a photo of a cold-weather install if useful." It wins on the three levers: speed (send it now), relevance (it answers the actual plain-English question), and credibility (a real, named, credentialed technician with a concrete detail) — and it drops the marketing/quote-request the original led with.

Exercise 23.26 †

The "5,200 total backlinks" number is nearly meaningless next to the referring-domain trend because raw backlink count is inflated by site-wide and repeated links — 5,200 links could come from a handful of domains and represent only a few real votes. The referring-domain line is the honest signal: it was flat at ~15 for four months, stepped to ~34 the month a cost-data report was published, then climbed slowly to ~46. The shape tells you exactly what worked: the original-data asset in month 5 was the catalyst (a step, not a smooth rise), and the subsequent slow climb is secondary citation as more writers found the now-established resource. Build more of the thing that caused the step.

Exercise 23.27

Ranking by link-earning potential: (b) local water-hardness map from own service data > (a) "10 plumbing tips" > (c) reprinted manufacturer spec sheet. (b) is original local data no one else has → strong citation obligation → most linkable. (a) has some value but exists on countless sites, so nothing obliges anyone to cite this one — traffic maybe, links rarely. (c) is duplicate content (someone else's material) — it earns nothing, may not even get indexed well, and adds no original value; it's the weakest by far.

Exercise 23.29 †

Two reasons to refuse: Durability — a fabricated or flimsy "study" (a made-up statistic propped up by a token survey) may get short-term pickup, but it torches your credibility the moment any journalist or competitor checks the methodology and finds nothing there; the links and trust evaporate and can take the brand down with them, whereas real data earns durable links. Ethics — it pollutes the information commons with false figures that other people will repeat as fact, and it violates the book's originality guardrail (Ch.13): the honest version (analyze your real data, state the methodology) is the only one that compounds. Faking data borrows trust it can't repay.

Exercise 23.30 †

(Illustrative — answers vary.) Example second asset: a "Rivertown Metro Emergency-Response Time & Seasonal Breakdown Report" — anonymized, aggregated data from Rivertown's own dispatch records showing which failures spike in which months (frozen pipes in January, AC failures in the first heat wave), by city. Proprietary vantage point: Rivertown's own service/dispatch logs across five cities — no one else has this local, seasonal, cross-trade data. The writer who'd cite it: a local news reporter or a "prepare your home for winter/summer" columnist needing local, seasonal specifics. What it can't do alone: it won't earn a single link without promotion — the outreach and local-PR plan is Ch.24, and measuring the resulting referring domains is Ch.27/30. (Also acceptable: a "which permit do you need in the metro?" wizard tool; a "cost of going all-electric in the metro" data piece.)

Exercise 23.31

(Guided — answers vary by site.) The deliverable is one sentence: your single best linkable-asset idea plus the proprietary vantage point that makes it yours. Example: "We'll publish an annual 'Regional Freelance Rate Report' from our own anonymized client-project data — the vantage point is our booking platform's real transaction records, which no competitor can replicate." Don't build it yet; naming it (and the vantage point) is the seed. Add it to the Appendix C link tracker.

Chapter 24 — Worked Solutions

Worked solutions to the daggered (†) and odd-numbered exercises. "Own-site" tasks give a model approach and what a strong answer looks like rather than a single correct answer.

Exercise 24.1

The four evaluation questions, in order: (1) Relevance — is the linking page/site topically and geographically related to mine? (2) Authority — how trusted and well-linked is the source itself (read DA/DR cautiously as a vendor model, not Google's number)? (3) Real traffic — does the page have a genuine audience, or does it rank for and receive nothing? (4) Editorial standards — does a human with judgment decide what appears, or will it link to anyone who asks or pays? The folding heuristic: "Would I want this link even if search engines did not exist?" If yes (it sends customers, reaches the right community, or associates you with a respected institution), it is almost certainly worth earning and one Google is glad to count.

Exercise 24.3

An editorial guest contribution is a genuinely useful article on a relevant, well-edited publication that reaches your audience, with a natural link you would want regardless of SEO. A guest-posting link scheme is thin/spun content mass-placed for keyword-rich links on sites chosen only because they will publish anything. The four things that actually separate them are intent (to inform/reach an audience vs. to manipulate rankings), scale (one real contribution vs. an industrialized campaign), quality (something you'd be proud to byline vs. filler), and relevance (a topically-matched publication vs. any site that accepts submissions). Note that the byline/format is identical in both — the format is not the differentiator.

Exercise 24.4

Broken-link building is finding a dead (404/removed) outbound link on a relevant, maintained page and offering your equivalent working resource as its replacement. It earns a better response rate than a cold "please link to my guide" because you are providing value first — you are helping the site owner fix a real defect on their page (nobody wants dead links), so the ask is framed as a favor to them rather than a favor to you.

Exercise 24.5

An unlinked mention is a place where your brand, product, or content is named in text but not linked. Reclaiming it is easier than most outreach because the hard part is already done: the publisher has already decided you are worth citing and put your name in their content. You are not persuading them of your value from scratch; you are asking them to complete a citation they already chose to make — a small, reasonable request most are happy to grant.

Exercise 24.7

Google's spam policies list link schemes including: (1) buying or selling links that pass ranking signals (including paid "guest posts" whose real product is the link); (2) excessive link exchanges ("link to me, I'll link to you" done to manipulate); (3) large-scale article campaigns or automated guest posting with keyword-rich anchor links; (4) automated programs that create links; (5) requiring a link as a condition of a service, contract, or terms of use; and (6) low-quality directory, bookmark, or "widget" links built for links rather than users. (Wording paraphrased; the common thread is links whose primary purpose is to manipulate rankings rather than to be a genuine editorial endorsement.)

Exercise 24.9

A stray reciprocal link — a supplier and a contractor naturally linking to each other because it genuinely helps their readers — is normal and harmless. A link exchange scheme is reciprocal linking organized at scale specifically to manipulate, including three-way and multi-site "link circles" engineered to hide the reciprocity. The line is intent and scale: a few natural reciprocal links that serve readers are fine; a system of swaps built to inflate link counts is a violation. Google's policy language is "excessive link exchanges," which points precisely at the scaled, manipulative version.

Exercise 24.11

Red flags in "Guaranteed placements on DA 50+ sites, \$120 each, keyword anchor of your choice, delivered in bulk": "Guaranteed" — links are earned, not guaranteed; a guarantee means the sites will place anything (no editorial standards). "DA 50+" — selling a third-party vendor metric Google doesn't use, priced as if it were Google's authority; the number is the pitch. "\$120 each" — paying for links that pass ranking signals is buying links, a link scheme, unless marked sponsored/nofollow (which the pitch clearly doesn't intend). "keyword anchor of your choice" — invites exact-match commercial anchors, the loudest over-optimization fingerprint (§24.7). "delivered in bulk" — scale is the tell; bulk placement is the definition of a link scheme, not editorial endorsement. Every one of the four evaluation questions fails. Correct response: decline, and distrust the vendor.

Exercise 24.13

Pursue the relevant DR 24 county builders' association, not the irrelevant DR 78 aggregator. Relevance is the first filter: a relevant link passes a more meaningful endorsement, and a pattern of irrelevant links is a manipulation signal, so the "big" irrelevant link is both weaker and slightly riskier. What the association link can do: pass a relevant, local, durable endorsement, send real referral traffic from actual local builders/homeowners, and reflect a genuine membership. What it cannot do: single-handedly move a competitive national ranking (its raw authority is modest). What the aggregator link can do: little of lasting value — an out-of-context mention. What it cannot do: carry relevance it doesn't have, or be the link you'd want if Google vanished. DR is triage, not the decision.

Exercise 24.14

The healthiest anchor-text distribution is an output of earning links because real people, writing naturally, overwhelmingly cite you by brand name, bare URL, or a natural phrase from their own sentence — so a brand-heavy, varied distribution emerges automatically when links are genuinely earned. You cannot "set" it honestly; you can only earn links and observe the shape they take. That is why managing your anchor ratios is a warning sign: to control the distribution you must be placing links and choosing their anchors, which is the manipulator's activity. The moment you are tuning ratios to "look natural," you have adopted the mindset the tactic is supposed to avoid. Safe practice: earn links; where you can influence an anchor, pick brand/URL/natural; never chase a target percentage.

Exercise 24.15

(a) Survivorship bias: "everyone gets away with it" counts only the sites currently ranking; it cannot see the sites that bought links, got caught, were demoted or deindexed, and vanished — nor the money quietly wasted on links SpamBrain already neutralized. The winners are visible; the casualties are invisible, which makes the tactic look safer than it is. (b) Expected value: EV = (probability of upside × its size) − (probability of downside × its size). The upside is modest and eroding (bought links are increasingly just neutralized). The downside is catastrophic and asymmetric — losing your entire organic channel, an asset built over years, plus a slow recovery. A small, shrinking upside against a ruinous downside is negative expected value. Rational businesses don't take that bet once they see both sides.

Exercise 24.17

Two reasons a real-traffic link is valuable independent of rankings: (1) Direct referral revenue — a mention on a busy, relevant page sends actual visitors who can convert (book a repair, buy a product) whether or not the link moves a single ranking; the link pays for itself in traffic. (2) It's a legitimacy proxy — pages that get real organic traffic are almost always genuine, editorially-maintained pages, so a traffic-rich source is far more likely to be a safe, high-quality link than a zero-traffic page (which is often part of a network built only to host links). Traffic is both a benefit and a filter.

Exercise 24.18

Diagnosis: the plumber bought (or was sold) a low-quality, at-scale link campaign. The evidence is textbook: 300 referring domains in six months (unnatural velocity), 90% unrelated ("business directories" and foreign blogs — irrelevant sources), and 55% exact-match "emergency plumber [city]" anchors (a statistically impossible-to-earn distribution — the over-optimization fingerprint of §24.7). This is a link scheme. Likely mechanism: algorithmic devaluation/demotion (Penguin-style link-spam systems now in core ranking, and SpamBrain neutralizing the spammy links so they stop counting) — which explains "flat, then a drop" — and possibly a manual action if a reviewer flagged it. Where the cleanup lives: Chapter 26 (auditing the toxic profile, deciding whether to disavow, and — if there's a manual action — a reconsideration request). The \$3,000 bought a liability; the fix is slow.

Exercise 24.19

This outcome is normal, not a failure. A single guest post — even an excellent one on a respected publication — rarely moves a ranking by itself, because ranking is a relative contest decided by many signals, and one link is one modest vote. What a single good guest post can do: put the creator's expertise and brand in front of a relevant new audience, send referral traffic, build a relationship with the publisher, strengthen author authority (E-E-A-T, Ch 5), and add one genuine editorial link to the profile. What it cannot do: rank a page on its own, or substitute for the accumulation of many earned signals over time. The correct read is "this is one good brick," not "the tactic failed." Guest posting compounds through relationships and repetition, not through any single placement.

Exercise 24.21

(Own-site task — model approach.) A strong answer pulls the top five referring domains from Search Console → Links → Top linking sites (or a free backlink-tool tier) and scores each honestly on the four questions: relevance (topical/geographic fit), authority (a rough sense, not just DA/DR), real traffic (does that page have an audience?), and editorial standards (real site or link farm?). It then applies the heuristic — "would I want this even without Google?" — and identifies which links are genuine assets (a relevant publication, an association, a real partner) versus noise (scraper directories, unrelated sites). Bonus for noticing any link that would be a red flag to a future auditor (irrelevant + optimized anchor) and flagging it for the Ch 26 conversation. What good looks like: a clear-eyed sort, no over-weighting of a single DA number, and a defensible "keep chasing this kind / ignore that kind" conclusion.

Exercise 24.23

(Prospecting task — model approach.) A strong answer runs at least two operators (e.g., your-topic intitle:resources, "your topic" "helpful links", your-topic inurl:links, or a .gov/.edu variant) and records five real resource pages, then judges fit honestly for each: does your best guide genuinely belong on this list, or is it a sales page that doesn't? The discipline being assessed is the "if" of §24.3 — resource-page links only work when your page truly deserves the spot. Credit answers that reject a prospect ("my page isn't good enough for this list yet — I'd need to improve it first") over answers that assume every page belongs everywhere.

Exercise 24.25

(Competitor-mining task — model approach.) A strong answer opens one competitor's referring domains in a free backlink-tool tier and sorts them into "replicable and relevant" (chambers, local "best of" listicles, supplier/manufacturer locators, sponsorships, real associations — sources open to you) versus "ignore" (scraper directories, one-time decade-old news features, unrelated junk). It reports the count of replicable sources (typically a small, recognizable set) and names the top three to pursue by evaluation score. The key judgment being assessed: mine for replicable, relevant sources — not the raw referring-domain count, and not the low-value directories that are noise rather than the reason the competitor ranks. Also credit the caveat that the tool shows a sample of the link graph, not Google's index.

Exercise 24.26

Rewritten plan: "New links should be earned, and where we can influence an anchor, it should use our brand name, our URL, or a natural phrase (e.g., 'Rivertown's AC repair page,' 'this AC repair guide'), not the exact phrase 'AC repair Cedar Hills.' We will not target an anchor distribution; a natural, brand-heavy profile will emerge from earning links." Why the change: the original "80% exact-match" plan is self-sabotage — a high share of exact-match commercial anchors is the clearest over-optimization signal there is, the very fingerprint Penguin was built to demote (§24.7). Real people almost never link with a commercial keyword phrase, so engineering 80% of anchors that way marks the profile as manufactured. The safe move is to under-optimize on purpose and let variety be the protection. There is no "safe ratio" to hit — the goal is earned links, not a dialed-in number.

Exercise 24.27

Rewritten outreach: "Hi [Name] — I was reading your home-maintenance resources page and noticed it's a genuinely useful list for local homeowners. We recently published a free guide, '[Signs Your Water Heater Is About to Fail],' that covers something your list doesn't yet — it might be a helpful addition for your readers. Either way, thanks for keeping such a useful page up." What changed and why: the original led with your benefit ("to boost my SEO") — the surest way to get ignored, and it signals you want a link for ranking rather than for readers. The rewrite leads with their audience's benefit, references their specific page (not a template), names a concrete gap your resource fills, and removes the SEO framing entirely. You are offering value to their readers; the link is the natural consequence, not the stated goal.

Exercise 24.29

Site X was earned; Site Y was engineered. Site X's profile is dominated by branded (44%), naked URL (20%), and natural (19%) anchors — exactly what real people produce when they cite a real brand in their own words. Site Y is dominated by exact-match (38%) and partial-match (25%) commercial anchors — a distribution almost impossible to earn by accident, because ordinary writers don't link with commercial keyword phrases. The single most telling number: Site Y's 38% exact-match commercial share (versus Site X's 2%); that one figure is the manipulation fingerprint. What you honestly cannot conclude: you cannot read a penalty, a ranking, or a "safe threshold" off these percentages. Google publishes no anchor thresholds and no safe ratio; the numbers show the shape difference between earned and engineered, not a target to hit or a precise line Site Y crossed. Diagnosing "engineered" is fair; asserting "therefore Y is at X% risk" is not.

Exercise 24.31

Refusal walkthrough. What it is: "a few extra sites we control to link to our main site" is a private blog network (PBN) — sites owned by one party built to link to a "money site" and simulate independent endorsement. Why it violates guidelines: it is a link scheme — the links exist only to manipulate rankings, not to reflect genuine editorial endorsement; the entire premise is fabrication. How it gets caught: footprints (shared hosting/IPs, similar registration, templated designs, thin link-only content, unnatural interlinking, and telltale anchor patterns) and machine detection (SpamBrain), plus human reviewers issuing manual actions. When caught, the links are neutralized and the money site can be penalized — losing the whole organic channel, sometimes overnight. What I'd do with the same budget instead: the four white-hat pillars — join the local chambers, sponsor a community event we'd support anyway, get listed on supplier/manufacturer locators, publish one genuinely useful data piece and pitch it to local press, and reclaim unlinked mentions. Slower, but it compounds instead of collapsing — and it's the version that survives the next update. The answer is no, and here's the better plan.

Exercise 24.33

(Rivertown Strategy-File extension — Millhaven, four white-hat pillars only.) A strong five-item plan, e.g.: 1. Pillar 1 (local relationship): join the Millhaven chamber of commerce for a member-directory listing. Anchor: brand ("Rivertown Home Services"). Limitation: modest authority; it's one relevant, durable link, not a ranking mover on its own. 2. Pillar 1 (sponsorship): sponsor a Millhaven youth sports team or the local food-bank drive the Delgados would back anyway. Anchor: brand or natural. Limitation: low individual authority; sponsor because they support it, not only for the link. 3. Pillar 1 (supplier): get listed on the "find a dealer" locator of an equipment brand Rivertown installs, tagged to the Millhaven service area. Anchor: brand/URL. Limitation: requires a real dealer relationship; can't be faked. 4. Pillar 3 (resource page): pitch Rivertown's "furnace won't turn on" guide to a Millhaven community or utility "winterize your home" resource page. Anchor: natural/title ("this furnace troubleshooting guide"). Limitation: low yield; only works if the guide genuinely belongs on the list. 5. Pillar 4 (unlinked mention): set a Google Alert for Millhaven-area coverage and reclaim any local story that names the branch without linking. Anchor: brand. Limitation: depends on mentions existing first; a new branch has few. Discipline: every anchor is brand/URL/natural — never "furnace repair Millhaven." Out of scope (correctly excluded): the inherited spammy links (Ch 26) and NAP/citation setup (Ch 25).

Chapter 25 — Worked solutions (daggered † and odd-numbered exercises)

Exercise 25.1

Relevance, distance (proximity), and prominence — Google's three stated local factors. The one you fundamentally cannot optimize is distance/proximity: you can't move your business closer to a given searcher. You influence the other two.

Exercise 25.3

The local pack (map + ~3 business listings, above the organic results) is driven primarily by your Google Business Profile. The localized organic results (the ordinary blue links below the pack) are driven by classic on-page and authority SEO, tinted by the searcher's location. They are different contests decided by different systems — you can win one while losing the other, which is why a great website can still be absent from the pack, and a great profile can sit above weak organic pages.

Exercise 25.5

A service-area business (SAB) serves customers at their locations rather than receiving them at its own premises. In its profile it may declare a service area and hide its street address (while still verifying a real one). Examples: plumber, electrician, HVAC company, house cleaner, mobile dog groomer — and Rivertown itself, which sends trucks to customers.

Exercise 25.6

It's incomplete because pack ranking is per-searcher and per-moment: proximity varies with where each person is standing, so there is no single universal "#1" — the pack changes as the searcher moves. Two follow-ups: (1) "#1 for which queries, and for searchers standing where?" and (2) "measured how — one check from your own office, or sampled across the whole service area?" (Ch 1's "for whom, where?"; Ch 30's location-aware rank tracking is the honest way to measure it.)

Exercise 25.7

Proximity is the one factor you can't optimize, and it's heavily weighted for "near me" intent. A single-office competitor — even one with better reviews — can only be the close option near its one address. A business with five real, well-optimized branches has five proximity anchors spread across the metro, so it can be the close, relevant, well-reviewed option across most of the map. The competitor wins their immediate slice; the multi-location business covers the factor its rival can only own locally — if each branch's profile is genuinely built and earns its own reviews.

Exercise 25.8

The most likely explanation is proximity: the searcher is physically near Competitor A, and distance is a primary, heavily-weighted factor that can outweigh a stronger review profile. Implication: your better reviews (4.8/180) still help you (a) where you're the close option — near your own location, where you win the geometry — and (b) at the conversion step everywhere, because a searcher's eye prefers the higher, deeper rating even when rankings are close. Reviews don't override standing-next-door proximity; they win the searches where you're already in contention and they win the click.

Exercise 25.9

Because reviews attach to a specific profile and don't transfer between locations, a multi-location business must run the review engine at every branch, not just headquarters. A large pile of reviews at HQ does nothing for the Millhaven profile's count and score. Practically: each branch needs its own asking process, its own review link/QR, and its own response routine.

Exercise 25.11

The primary category tells Google what the business fundamentally is and strongly determines which searches you're eligible for — it's the strongest single relevance lever. Choosing it wrong (too generic, or simply the wrong category) doesn't make you rank low for your core queries; it can make you ineligible and invisible for them. Getting it right (the most specific accurate category) is often the difference between appearing at all and not.

Exercise 25.13

The cause is proximity. The plumber has done relevance (complete profile) and prominence (120 genuine reviews) well, but distance is a primary factor and they simply aren't close to searchers across town. What's achievable, honestly: they can realistically win the pack for searchers near their location and compete in localized organic citywide; they cannot expect the pack for far-away searchers short of a real presence there. The SAB setting can extend eligibility across a declared service area, but it doesn't manufacture proximity. Honest framing: better odds where you're close, not a decree across the whole town.

Exercise 25.15

Three distinct likely causes: (1) Relevance/verification (§25.2) — the four branch profiles are unclaimed, unverified, thin, or miscategorized, so they're not eligible for their local queries. (2) Reviews (§25.3, §25.7) — reviews are concentrated at HQ and the branches have few or none, because reviews don't transfer between profiles. (3) NAP/filter or thin pages (§25.4/25.5/25.7) — inconsistent NAP or near-duplicate profiles/pages trigger the local filter or fail to rank in organic. Fix: claim and complete every profile, run a per-branch review engine, clean NAP, and rebuild the branch pages as genuine local resources.

Exercise 25.17

(Process solution.) Search Google for the business's phone number in quotes and record every place its NAP appears; flag each conflict — old business name, wrong/added suite, dead phone number, or (worst) a duplicate profile that splits your identity. The three worst to fix first are (a) any second/duplicate Google profile, (b) conflicts on the high-authority majors (Apple, Bing, Yelp, Facebook, BBB), and (c) wrong phone numbers anywhere, since they misroute customers and split call data. That list is a citation audit — the same output a paid tool automates, done free for one business.

Exercise 25.19

The usual pattern: the three pack businesses (a) carry the specific primary category that matches the query, (b) tend to have higher and more recent review counts, and (c) show real, non-stock photos. The takeaway: category + reviews + genuine media are the visible commonalities you can act on; proximity is invisible in the snapshot — some of what put them there is simply that they were close to where you searched from.

Exercise 25.20

(Example set; label may vary by business.) Local-intent (Google auto-localizes, no "near me" needed): "furnace repair," "emergency plumber," "electrician [city]," "24 hour plumber," "AC repair near me," "best HVAC company [city]." Not primarily local: "how to relight a pilot light," "what size furnace do I need" (informational). Navigational/branded: "Rivertown Home Services." Key observation: nearly all the service queries are localized by Google whether or not the words "near me" appear.

Exercise 25.21

Genuine pages: the five real branch cities (Rivertown, Cedar Hills, Northgate, Westbrook, Millhaven) — real presence, real substance. A neighboring town served via SAB can earn a substantive service-area page if there's genuine, unique local content to write (real jobs done there, local specifics). Towns with no presence and nothing true and unique to say = doorway pages — don't create them. The line: is there genuine, unique, true local substance? If not, the page is a doorway regardless of the keyword in the URL.

Exercise 25.22

Outline for the rebuilt page: H1 "Furnace Repair in Northgate | Rivertown Home Services"; the real Northgate branch address + an embedded map; the local phone and hours; named, photographed technicians who serve Northgate; a section on common Northgate furnace issues (the area's housing stock, climate demands, a cold-snap checklist); real job photos taken in Northgate; two or three Northgate customer reviews; internal links to the furnace-repair and emergency-service pages; a clear click-to-call CTA. Each element is something only a genuine Northgate operator could provide — which is exactly why it earns the ranking the generic "best in Northgate" claims never could.

Exercise 25.23

Sample (compliant, frictionless, no gating/incentive): "Hi [name], this is [tech] from Rivertown Home Services — glad we got your heat back on tonight. If you have 30 seconds, a quick Google review really helps our family business: [short review link]. Thanks either way, and call us anytime." It goes to every customer, offers no reward, and is one tap.

Exercise 25.25

Two things to act on: (1) the 78% non-branded ("discovery") share shows the profile is pulling new customers, not just people searching the brand — lean into it by making sure categories and services cover more of those non-branded queries. (2) With 90 calls vs. 60 website clicks, the profile converts to calls well — make the call action and booking even more prominent, and confirm hours/address are perfect so the 140 direction requests don't hit a wrong door. What the data does not tell you: your ranking/position in the pack, or whether those actions became booked, paid jobs — profile actions are not revenue; tie them to GA4/CRM (Ch 28) to know that. (All figures are a constructed example.)

Exercise 25.27

What's wrong: it treats citations as a volume game and implies a ranking guarantee — both false. Honest version: consistent NAP across a short list of quality sources (Google, Apple, Bing, Facebook, Yelp, the BBB, your main industry directories) is worth doing as hygiene that resolves ambiguity; the marginal value of the 500th low-quality directory is near zero and can be noise. Fix conflicts, cover the majors, and put the freed energy into reviews, content, and links — which have real headroom. No package "climbs the pack."

Exercise 25.29

On Google-policy grounds this is review gating — soliciting Google reviews selectively from predicted-happy customers — which Google's policies prohibit. On U.S. legal grounds, the FTC's 2024 rule bans deceptive review practices including suppression, with penalties; the Fashion Nova settlement (\$4.2M, 2022) shows real enforcement of a related practice. Compliant alternative: send the same request and link to every customer, don't screen by predicted rating, and respond publicly to the negative reviews (which are also where you learn what to fix). The honest engine is also the legally safe one. (Description of public rules, not legal advice.)

Exercise 25.30

Review-engine SOP (one branch). Who asks: the lead technician at job completion, plus a next-day office follow-up. When: immediately after a successful, completed job, while the customer is satisfied. Tool: the branch profile's short review link as a QR leave-behind card and a one-tap SMS/email link. Responses: the office replies to every review within ~2 business days — a brief thanks for positives, a calm, take-it-offline resolution for negatives. Cadence: weekly check of new reviews; monthly review of count/rating/velocity per branch. What it cannot promise: that it will win the local pack or any specific rank — proximity and competitors are outside its control. It earns better odds and a stronger conversion signal, never a guaranteed position.

Exercise 26.1

A toxic link is the industry/tool-vendor term for a low-quality or manipulative inbound link presumed to risk harming your rankings; unnatural links is Google's own term for links created primarily to manipulate rankings rather than earned on merit (bought/sold, exchanged, PBN, automated, anchor-stuffed). The difference is more than pedantic because "toxic link" is a vendor category — Google publishes no toxicity signal and has said these scores do not reflect its assessment — so acting on a "toxic" flag means acting on someone's guess, whereas Google actually acts (rarely) on unnatural links you created. Translating "toxic" into "did I build a manipulative link?" changes the response from reflexive cleanup to a provenance judgment: usually nothing to do.

Exercise 26.2 †

A manual action is a penalty applied by a human reviewer at Google for a confirmed spam-policy violation; an algorithmic demotion (Ch 6) is a ranking drop caused by an algorithm/update reassessing your site. The single most important observable difference, checkable in ten seconds: a manual action comes with a notice in Search Console's Manual Actions report (Security & Manual Actions), while an algorithmic demotion is silent — no notice, nothing to see there. Notice = manual; "No issues detected" = not a manual action (look to algorithmic or technical causes).

Exercise 26.3

The disavow tool is a Search Console feature (2012) that lets you upload a text file telling Google to ignore specified inbound links or whole domains when it assesses your site. Google's own guidance: most sites should never use it — the vast majority do not need it because Google already ignores the links they would want to disavow.

Exercise 26.5

A reconsideration request is a formal submission through Search Console asking Google to review your site and lift a penalty after you have fixed the violation. The one and only condition under which it does anything: you have a manual action. For anything else — a core update, an algorithmic demotion, a technical drop — it does nothing, because there is no human-issued action for a reviewer to reconsider.

Exercise 26.7 †

Mechanically: when a stranger's spammy link points at your site, Google's link-spam systems assess it, judge it the kind of manipulative/worthless link that should not pass credit, and ignore rather than penalize it — they simply give it no weight. Your rankings do not move because the link was never counted. This follows from how the systems evolved after 2016 (Ch 6): early Penguin (2012) could penalize a site for manipulative inbound links, but Penguin went real-time and granular in 2016 and, with SpamBrain, shifted to devaluing/ignoring bad links rather than punishing the site they point at. So a bad inbound link you did not build is inert litter — wasted effort by whoever made it — not a liability you carry.

Exercise 26.9

The disavow tool is "a loaded gun pointed at your own authority" because every link you disavow is a link Google will stop counting. Links are how authority (PageRank) flows into a site (Ch 22); a genuine inbound link is a vote that contributes to your rankings. If you disavow a link that was actually helping you — and tool "toxicity" flags catch legitimate links constantly (false positives) — you have deliberately severed a real vote, removing authority you were receiving and potentially lowering your own rankings. It is the one tool that lets you damage your own authority by hand, and reversing it (removing the domain from the file, waiting for a re-crawl and re-credit) is slow. Upside of an unnecessary disavow: zero. Downside: self-inflicted loss.

Exercise 26.11

Disavowing after a core update is useless and potentially harmful. Useless: a core-update drop is an algorithmic reassessment of quality, not a link penalty — there is nothing link-related to undo, so disavowing changes nothing about the actual cause. Harmful: in the panic you will disavow links a tool flagged "toxic," some of which are legitimate links helping you; telling Google to stop counting them removes real authority and can push your rankings lower, deepening the very drop you were trying to fix. The correct response to a core update is Chapter 6's: genuinely improve quality and wait for reassessment — never the disavow tool.

Exercise 26.13

"Inbound litter" is spammy links other people point at you (directory spam, scraper links, a competitor's junk); "a self-created scheme" is manipulative links you or a vendor acting for you built or bought. The one question the tools cannot answer is the provenance question: did we create this link to manipulate rankings? No tool knows your history, so no score can answer it — only you can. It is the real fork because Google penalizes/discounts self-created manipulation while ignoring inbound litter; so provenance, not any toxicity number, decides whether the correct action is "deal with it" (rare) or "do nothing" (usual).

Exercise 26.15 †

(a) Manual action — the Manual Actions report shows an explicit "Unnatural links to your site" notice, which by definition is a human-issued penalty. (b) First check you have already done — the Manual Actions report — and it is the fork: a notice puts you on the manual-action path. Next, confirm the scope (site-wide vs. partial) and read the example URLs (a sample of the pattern, not the whole list). (c) Both apply: this is exactly where the disavow tool and the reconsideration request belong — remove the manipulative links you can, disavow the rest, document the cleanup, and file a reconsideration request. This is the one scenario in the chapter where "do something" is unambiguously right.

Exercise 26.17

(a) Not a penalty at all — a technical problem. Traffic going to essentially zero overnight, a clean Manual Actions report, and "Excluded by noindex" climbing site-wide is the accidental-noindex catastrophe (Ch 14, first named in Ch 1 §1.4), not a link issue and not an algorithmic demotion. (b) First check: load a live page and inspect a URL in Search Console; you'll find the site is telling Google not to index it. (c) No disavow role whatsoever — there is no link problem. Fix: remove the noindex/robots block from every template, verify on the live site, resubmit the sitemap, request indexing for key pages. Act immediately; every hour more of the site falls out.

Exercise 26.19

(a) It is a form of negative SEO, but (b) it is not a link problem at all — it is a reputation attack. Fifteen fake one-star reviews from no-history accounts is a fake-review attack on the Google Business Profile. (c) It is handled in Chapter 25 (Local SEO): report the policy-violating reviews to Google for removal, respond professionally to any that remain, and keep earning genuine reviews to dilute the fakes. The disavow tool and the Manual Actions report are irrelevant here. This is the §26.7 lesson that the real forms of negative SEO are security/content/reputation problems, not "toxic link" problems.

Exercise 26.21 †

(Guided — answers vary by site.) The deliverable is a real record from the free GSC Links report: top 10 linking sites and top 10 anchor phrases, plus a written judgment. The skill checked is reading a profile for provenance and pattern, not a score: healthy anchor text is mostly brand/URL/generic; a tell is exact-match commercial phrases repeated heavily. A good answer traces any suspicious cluster to something the owner/vendor did — and, for most readers, concludes with "nothing to do," because the profile is harmless junk they did not build. A learner who reaches "do nothing" for the right reason (no self-created scheme, no manual action, Google ignores the junk) has understood §26.2, not just performed an audit.

Exercise 26.23

(Guided.) The deliverable is a two-line decision memo on the single lowest-quality link: litter (ignore) or self-built (address), justified by provenance rather than a toxicity score. A good memo names the provenance test explicitly ("we did not build this — it's a scraper/directory listing — so it's inbound litter Google ignores; no action") or, in the rarer case, ("this matches a campaign we ran; it's self-created; assess for cleanup"). The point of the exercise is the reflex: the worst-looking link is almost always the one you should do nothing about, because ugliness is not the risk criterion — provenance is.

Exercise 26.25 †

What has happened: a manual action for unnatural links to your site, applied to the entire site by a human reviewer — a real, notified penalty. The "3 example URLs" are a sample Google chose to illustrate the pattern; they are not the full list — the cleanup must address the whole manipulative pattern, not just those three. The first three things you do, in order, before touching Request Review: (1) Understand the full pattern — audit the profile (§26.2) to find all the links of that kind, not just the examples. (2) Remove what you can — real outreach to get the manipulative links taken down, documenting every attempt. (3) Disavow the rest — the links you cannot get removed go in a disavow file (this is the tool's true home). Only after genuine, documented cleanup do you write an honest reconsideration request and click Request Review. Filing before cleaning up earns a rejection.

Exercise 26.27

Three false/misleading claims. (1) "Toxic links" as a category to police — a vendor term, not a Google signal; honest version: "Google ignores manipulative inbound links you didn't build; there is no toxic-link problem to monitor." (2) "Disavow every month to protect from penalties" — routine disavowing prevents nothing and risks removing good links; honest version: "the disavow tool is for cleaning up a scheme you built, and most sites should never use it." (3) "Protect you from negative SEO" — the link version of negative SEO is mostly a myth because Google ignores those links; honest version: "competitor link attacks almost never work; the real risks are hacking, scraping, and fake reviews, which this service doesn't address." The tell across all three: selling ongoing defense against dangers Google already neutralizes.

Exercise 26.28 †

Honest recommendation: do not disavow the 1,900 links. The site was hit by a core update (no manual action), which is an algorithmic demotion — there is no link penalty to undo, so disavowing does nothing about the cause and actively risks harm by removing legitimate links the toxicity model misjudged (§26.3, §26.6). What I would refuse: uploading a mass disavow file on a tool's toxicity score, because that is "amputating a healthy limb to cure a headache" — it can lower rankings for zero benefit. What I would do instead: confirm the diagnosis (Manual Actions report is clean; timing matches a confirmed core update), then run Chapter 6's recovery — honestly audit and improve the weakest content, prune/deepen, strengthen genuine E-E-A-T — and wait for reassessment, diversifying traffic in the meantime. The client wants action; the correct action is quality work, not a disavow that would make the hole deeper (Case Study 2).

Exercise 26.29

Two-sentence reply: "You're right that negative SEO is real — but the real forms are hacking, content scraping, and fake reviews, which are security, content, and reputation problems, not link problems. The version people fear — a competitor tanking your rankings with spammy links — is overwhelmingly a myth, because those are exactly the links Google already ignores, so pointing more of them at you accomplishes nothing." The genuine security threat among them is hacking — a compromised site injected with spam/redirects, which can even draw a hacked-site manual action — and it is defended by owning and securing your infrastructure, not by disavowing.

Exercise 26.31

Rivertown's decision: ignore, do not disavow the inherited spammy links. The four ordered reasons: (1) No manual action — the Manual Actions report says "No issues detected," so there is no penalty to recover from and the disavow tool's one real job doesn't apply. (2) The links aren't the bottleneck — Rivertown barely ranks for non-branded terms because its pages are thin and its local SEO is absent (Ch 25), not because it is being demoted. (3) Google already ignores them — a small, dated, low-quality cluster is exactly what SpamBrain/real-time Penguin neutralize automatically. (4) Disavow has downside, no upside — filing risks catching a borderline-legit link, costs effort, and buys false confidence for zero ranking gain. The two conditions under which the Delgados would revisit and actually disavow: (a) if Rivertown ever receives an unnatural-links manual action, or (b) if the old vendor were still actively building/buying links Rivertown couldn't stop. Neither is true, so: no disavow.

Exercise 27.1 †

The four Performance-report metrics: Impressions — the number of times a link to your site appeared in Google's results for a search (an appearance, not a view or click). Clicks — the number of times a searcher clicked through from the results to your site. Click-through rate (CTR) — clicks divided by impressions, as a percentage; the efficiency of your listing. Average position — the average ranking position of your topmost result across the impressions in view (an average, not a live rank).

Exercise 27.3 †

Average position is a single number averaged across every impression in the date range — so a page that ranked #1 for some searchers and #9 for others (ranking is personalized by location and device, Ch 1) can show an "average position" of, say, 4.6, a position that never actually existed for anyone. It is therefore a trend to watch over weeks (climbing or falling), not a live leaderboard rank; for a location-specific rank you need dedicated rank tracking (Ch 30).

Exercise 27.5

The two property types are the Domain property and the URL-prefix property. A Domain property covers something a URL-prefix property does not: the entire domain — every subdomain (blog., shop.) and both http:// and https:// — in one view (verified by a DNS record). A URL-prefix property covers something the Domain property setup can't offer: easier verification by multiple methods (HTML file, HTML meta tag, Google Analytics, or Google Tag Manager), at the cost of covering only the one exact address you enter.

Exercise 27.6 †

A listing problem, not a ranking problem. At position ~3 the page is already on page one and being seen; a 0.9% CTR means searchers are looking and choosing someone else — a failure of the listing (title tag and meta description) or an intent mismatch, not of the page's ability to rank. The fix is to rewrite the title to answer the query directly and tighten the description into genuine ad copy (Chapter 9), and confirm the page matches the query's intent (Chapter 3). Do not rewrite the whole page — it's ranking fine.

Exercise 27.7

Because at position 24 the page is on page three, where almost nobody scrolls — so the low CTR is simply a consequence of position, not of a weak listing. Rewriting the title changes nothing, because the listing barely gets the chance to be clicked in the first place. The correct response is to help the page climb onto page one (better content and intent match, internal links — Ch 3, 9, 15); the title work only starts paying off once the page is actually being seen. Same "low CTR," opposite diagnosis — which is why you must read CTR together with position.

Exercise 27.8 †

Yes — the SEO is working, and this is exactly the situation where you must say so with evidence. Average position climbing from ~15 (page two) to ~9 (bottom of page one) across priority queries is real, trustworthy progress; clicks are flat only because everything below the very top of page one is still the traffic graveyard — the clicks arrive in a rush after the pages cross into the top results. To the impatient owner: "We're winning the contest before the traffic shows up; the pages are climbing steadily and are one push from the click-earning positions — pulling out now would waste the gains." This illustrates theme 6 (SEO is a long game): average position is where you see the game being won before the traffic arrives.

Exercise 27.9

Two explanations. (1) SERP features / AI Overviews: the queries you're appearing for now trigger an AI Overview, featured snippet, or "People Also Ask" box that sits above you and absorbs clicks (Ch 10, 36) — more impressions, lower CTR, without your listing getting worse. (2) You're ranking for new but lower/less-relevant queries: you're appearing more (higher impressions) but at positions or for intents that don't earn clicks. To tell them apart: segment the queries — are the new impressions concentrated in informational queries (points to SERP features) or spread across low-position terms? — and run a live search on the top query to see whether an AI Overview or feature is intercepting the click.

Exercise 27.11 †

The "top ten queries" list is trustworthy because it's Google's own record of real searches your site appeared and was clicked for — those ten queries and their metrics really happened. But reading it as "all our traffic" is always wrong because of data anonymization: Search Console deliberately omits rare or potentially identifying queries to protect searchers' privacy, so the queries it shows never sum to the reported totals. There is always a tail of anonymized queries you cannot see — often large for sites with lots of long-tail traffic. So: your visible top ten is a real top ten; it is never the whole picture.

Exercise 27.13 †

Walk the pipeline (Ch 1) in order. (1) Discovery — does Google know the page exists? Check that it's linked from somewhere on the site (not an orphan, Ch 15) and included in the XML sitemap (Ch 14); nothing gets impressions if Google never found it. (2) Crawl/index — has Google actually indexed it? This is where URL Inspection comes in: inspect the URL and read whether it's "on Google," when it was last crawled, and whether crawling/indexing were allowed. If it says "URL is not on Google," you've found the problem before ever wondering about ranking. (3) Only then, ranking — if it is indexed but still gets zero impressions, the page may simply not be judged relevant/competitive enough to appear yet (content, intent, links). Diagnose the earlier stages first; a not-yet-indexed page can't earn a single impression, so "the content isn't good enough" is the last question, not the first.

Exercise 27.15 †

"View Crawled Page" shows the version from Google's last crawl, which predates your rewrite — Google simply hasn't re-crawled the page yet, so its stored copy is still the old content. Steps, with honest limits: (1) Run Test Live URL to confirm the new content renders correctly right now (and appears in the rendered HTML). (2) Click Request Indexing to add the URL to a priority crawl queue — this nudges Google to re-crawl sooner, but it does not re-crawl on demand, guarantee re-indexing, or affect ranking, and there's a daily quota, so click it once. (3) Ensure the page is well-linked and in the sitemap so Google re-crawls it naturally. Then wait — the "Last crawl" date and the crawled content update on Google's schedule, typically days, not minutes. There is no button that forces an instant refresh.

Exercise 27.17 †

(Guided — answer varies by site.) The deliverable is a real record: which property type you chose (Domain if you can edit DNS and want whole-site coverage; URL-prefix if you can only edit the site's <head> or connect Analytics/Tag Manager), which verification method you used, and one sentence on why it fit your access. A strong answer connects the choice to access: e.g., "I used a Domain property verified by a DNS TXT record because I control the domain registrar and wanted www, non-www, and the blog subdomain all in one view," or "I used a URL-prefix property with the HTML meta-tag method because I can edit the WordPress theme header but don't have DNS access." The learning is that the property/verification choice is dictated by what you can actually edit.

Exercise 27.19

(Guided.) The deliverable is your real Indexed and Not-indexed counts plus a danger triage: did you find any page you want ranking sitting under "Excluded by 'noindex' tag," "Blocked by robots.txt," or "Not found (404)"? A good answer either flags a genuine problem (e.g., "three service pages are noindexed — a real, high-value loss to fix per Ch 14") or reports, correctly, that all the not-indexed pages are genuinely low-value (old tag archives, filter URLs, thin posts) and there's nothing alarming — which is a valid, common, and reassuring result. The skill demonstrated is reading the report by intent and danger, not by chasing 100% indexation.

Exercise 27.20 †

(Guided.) The deliverable is a real URL Inspection read of your most important page: (a) Is it "on Google"? (b) When was it last crawled? (c) Did Google's chosen canonical match the one you declared — if not, that's a silent problem worth investigating (Google may be indexing a different version). Then, via Test Live URL → View Tested Page → HTML, confirm that a distinctive sentence from your main content appears in the rendered HTML — proving Google can actually see your content after any JavaScript runs (the Ch 19 test). For a WordPress/server-rendered site, expect a clean pass; the value is in verifying from Google's own renderer rather than assuming.

Exercise 27.21 †

(Guided.) The deliverable is three real "accidental relevance" queries from your query report — terms you get impressions for but never targeted — each with a decision and justification. The reasoning to look for: a query with meaningful impressions and a distinct intent from your existing pages usually deserves its own page (Ch 7, 8) — Google is telling you there's demand it thinks you're relevant for. A query that's a variation of an existing page's topic is better served by adding a section to that page (avoiding cannibalization, Ch 12). A query that's irrelevant, off-brand, or a fluke gets nothing. The skill is treating the query report as a free demand-discovery tool, not just a scoreboard.

Exercise 27.23

The original is a classic listing failure: the title is the site's generic boilerplate ("Blog — Rivertown Home Services") that says nothing about the searcher's problem, and the description is company boilerplate that ignores the query entirely. At position 4 for a frightened searcher, that listing gives no reason to click. A rewrite that earns the click: - Title: Furnace Short Cycling? Causes and How to Fix It | Rivertown Home Services (answers the exact query, front-loads the problem, keeps the brand at the end). - Meta description: Furnace turning on and off every few minutes? Learn the common causes — dirty filter, thermostat, oversized unit — what you can check yourself, and when to call a pro. (promises the answer and the follow-up questions searchers have). Change nothing about the ranking work; verify the CTR in Search Console in 2–3 weeks (Ch 9).

Exercise 27.25 †

Three bullets: - Rivertown is essentially invisible for new-customer searches. The top queries by impressions are non-branded and sit at positions 12–19 (page two) with sub-0.5% CTR — high demand, near-zero capture. The site appears for what customers search but doesn't rank well enough to be clicked. - The real traffic is branded. The top queries by clicks are the business's own name at position 1–2 — people who already know it. The overall 3.0% CTR is propped up by these; strip them out and the non-branded CTR is dismal. - The opportunity is large and quantified. ~90,000 monthly impressions, mostly stranded on page two, is a prioritized worklist: move those queries onto page one (content, intent, internal links) and the clicks follow. What the data does not tell you: whether any of those clicks became customers (calls, bookings) — that's Chapter 28 (GA4) — nor why each page ranks where it does, nor who the competitors are (Ch 30).

Exercise 27.27 †

The term is index bloat: Google has indexed far more URLs (320) than you have real pages (~150). Likely causes (all owned by Ch 14): parameter/filter URLs each indexed as a separate page, tag/category archives, paginated pages, session or tracking parameters, http and https or www and non-www versions both indexed, or attachment/auto-generated pages (common on WordPress). Where to investigate: the Page indexing → Indexed list in Search Console (scan the actual indexed URLs for junk patterns), and then apply Chapter 14's tools — canonicals, noindex on the low-value templates, and parameter handling — to get the junk out of the index. Index bloat dilutes your site's quality signal and wastes crawl attention on pages that will never rank.

Exercise 27.29 †

What's wrong: "Crawled – currently not indexed" does not mean the site is broken, and you should not try to force every such page into the index. It's a mild quality signal — Google crawled the page and judged it not (yet) worth storing — and for genuinely thin, old, or duplicative pages (which most flagged pages are) that verdict is often correct; those pages were never going to rank. The honest version: read the status by intent and danger. It's worth acting on only when a page you genuinely want ranking is caught in it — and then the fix is to make the page substantially more useful/unique (Ch 9, 12), not to spam Request Indexing. Chasing 100% indexation of thin pages is wasted effort; the emergencies are the small "Excluded by noindex/404" lines, not this pile.

Exercise 27.30 †

Correct access method: add the vendor as a user under Settings → Users and permissions (Full or Restricted access), which lets them work in your property without ever seeing your password — and you can revoke it instantly when the engagement ends. The password request is a red flag because it hands over your entire Google account (email, other properties, everything), can't be scoped or cleanly revoked, and no legitimate vendor needs it when per-user access exists; it signals either sloppiness or bad intent. The privacy point in Search Console's favor: unlike the user-level analytics of Chapter 28 (which track real people's behavior and raise genuine consent/GDPR/CCPA questions), Search Console reports only aggregate, anonymized search data — it never exposes an individual searcher — so granting scoped access to it carries far less personal-data risk in the first place.

Exercise 27.31 †

Rivertown — First Month in Search Console: Findings Memo (for Tony & Marisa Delgado). Three highest-priority findings: (1) We are invisible for new customers. Our ~7,600 monthly clicks (≈ the ~8,000 organic visits we knew about) are almost entirely people searching our own name; for the searches that bring new customers ("ac repair near me," "furnace repair Cedar Hills," "water heater replacement cost") we appear ~190,000 times a month but sit on page two and earn almost no clicks. The demand is there and Google already considers us relevant — the gap is rankings-and-listings work. (2) Real service pages are still accidentally hidden from Google by the leftover noindex (the "Discourage search engines" checkbox) Chapter 14's audit caught — a self-inflicted, high-value loss. (3) The index is bloated — Search Console shows ~1,400 URLs "indexed" against only ~120 real pages (tag archives + parameters), and our five location pages are near-duplicates Google keeps collapsing — confirming the technical + thin/duplicate diagnosis. Fix this week: remove the leftover noindex hiding the real service pages (Chapter 14) — it's fast and pure upside. What this data does NOT yet tell us: whether any of those clicks turn into booked jobs — Search Console stops at the click. That's Chapter 28 (Google Analytics 4), where we'll set up conversion tracking for calls, forms, and bookings. (All figures constructed/illustrative.)

Chapter 28 — Worked solutions (daggered † and odd-numbered exercises)

Exercise 28.1

• Event — the atomic unit of GA4 measurement: any single recorded interaction (a pageview, scroll, click, form submit, purchase), described by parameters.
• Engaged session — a session that lasted >10 seconds, had 2+ page/screen views, or included at least one key event.
• Engagement rate — the share of sessions that were engaged (engaged ÷ total); GA4 bounce rate is its inverse.
• Key event — an event you've marked as representing business value, so it counts as a conversion in reports.
• Attribution — the rules for assigning credit for a conversion to the touchpoints along the path that produced it.

Exercise 28.3

An engaged session meets at least one of three conditions: (1) it lasted longer than 10 seconds (the threshold is adjustable up to 60s), or (2) it had 2 or more page/screen views, or (3) it included at least one key event. In GA4, bounce rate is the inverse of engagement rate: $\text{bounce rate} = 1 - \text{engagement rate}$ — the percentage of non-engaged sessions. (Note: this is a different definition from Universal Analytics' bounce rate, which was single-page sessions — don't compare the two.)

Exercise 28.5

The concept is a conversion (a completed, valued action). Universal Analytics called it a Goal; early GA4 called it a conversion; since 2024, GA4 calls it a key event (reserving "conversions" for the ads-oriented metric). Same idea, three names — so when an older tutorial says "mark a conversion," today you "mark a key event."

Exercise 28.6

Traffic acquisition is session-scoped: it credits each visit to the source that brought that visit. User acquisition is user-scoped: it credits all of a person's visits to how they first arrived, ever. For "how much did organic drive this month, and how did those visits behave?" use Traffic acquisition, filtered to Session default channel group = Organic Search — because you want this period's organic sessions attributed to organic, not every visit from someone who once first arrived via organic. Using User acquisition here would mis-credit organic with visits it didn't drive this month (and vice versa).

Exercise 28.7

GA4's Direct is a "junk drawer" because it collects not just people typing your URL but every visit GA4 couldn't attribute — untagged links, some app referrals, and sessions where the referrer was stripped by privacy tooling. A rise in Direct can be good news for an SEO because branded traffic — people who learned the name (from a truck, a review, an earlier organic visit) and return by typing the URL or a bare brand search — often lands in Direct. So Direct tends to move with brand-building and SEO's downstream effects; it's frequently SEO's shadow, not a separate, unrelated channel.

Exercise 28.8

The error: it assumes Google reads your GA4 engagement rate and ranks you on it. It doesn't — Google has stated on the record that it does not use Google Analytics data as a ranking signal. So a better engagement rate does not cause a ranking rise. The legitimate value: a higher engagement rate means the redesign is genuinely satisfying more visitors — which is correlated with the things that do help rankings (matched intent, useful content) because they share a cause. Use it as evidence the page serves people better and as a diagnostic for what to fix next — just don't sell it to the client as a ranking lever.

Exercise 28.9

SEO is very often the first touch — the informational search ("why is my furnace short cycling") that first introduces a stranger to a business. The final click before a conversion is frequently a branded search or a Direct visit (often itself the fruit of that earlier organic discovery). Last-click attribution awards 100% of the credit to that final touch and 0% to the organic search that started the journey — so a good SEO program's real contribution is hidden, and a strategist who reports on a last-click basis is, in effect, arguing for their own budget cut.

Exercise 28.10

No tool can join a specific organic query to a specific person's conversion because Google secured its search query data — beginning with encrypted search in 2011, the "(not provided)" change — so the query is no longer passed to your site and never reaches your analytics. GA4 knows that a visit came from organic search and everything it did afterward, but not what was searched. Search Console knows the query but reports it aggregated and separately from on-site behavior, never tied to an individual. The wall between query and visitor behavior is deliberate and permanent; any tool claiming to show "the exact keyword each visitor searched and what they earned" is selling a fiction.

Exercise 28.11

A booking-request key event does not prove: (1) that the lead was real — spam and mis-fills happen; (2) that anyone answered or contacted the person; (3) that the request became a booked, kept, or paid job. GA4 sees the request; the outcome lives in the scheduling system and CRM. (It also doesn't prove the request came from a unique person — one visitor may submit twice.)

Exercise 28.12

Data-driven attribution needs sufficient conversion volume to train its model. On a low-traffic site, there aren't enough conversion paths for the machine-learning model to find stable patterns, so the credit it assigns to each channel can swing erratically month to month. This is a known limitation, not a bug: DDA is a model that requires data to be reliable. For a very low-volume site, a simpler, transparent model (or simply reading conversion paths directly) may be more trustworthy than an unstable data-driven output.

Exercise 28.13

• /blog/furnace-short-cycling — 1,100 sessions, 74% engaged, 3m10s, 2 key events. A top-of-funnel informational winner: it pulls and holds the most organic traffic but barely converts, which is expected for an informational page. Change: add a gentle next step (an internal link + "book a tune-up" CTA) to capture a little of that held attention. Don't mourn the low conversions.
• /ac-repair — 400 sessions, 62%, 1m40s, 21 key events. A healthy commercial/service page doing its job: decent traffic and real conversions. Leave it; maybe study it as a model for other service pages.
• /locations/millhaven — 300 sessions, 29%, 18s, 1 key event. The alarm. Real traffic arrives and leaves almost instantly — a thin/duplicate location page, an intent mismatch, or a technical problem. Investigate (Chapters 25, 9, 16/17).
• /book — 70 sessions, 55%, 58s, 33 key events. The finish line: few sessions, high conversions.
• A traffic-only report would wrongly crown the furnace blog as "best" and call /book (70 sessions) the worst — exactly backwards on value. Read landing pages as a portfolio, not a leaderboard.

Exercise 28.15

The feature is data thresholding: GA4 withholds data (hides rows, or a whole breakdown) when the numbers are small enough that an individual could theoretically be re-identified — it triggers most often when Google Signals or demographic data is enabled. It exists to protect user anonymity, a privacy feature by design. It does not mean your tracking is broken; it means GA4 is refusing to show you data it judges could compromise anonymity. If you need those rows, you can sometimes reduce thresholding by widening the date range, removing demographic dimensions, or turning off Google Signals — accepting the trade-offs.

Exercise 28.17

Two reasons the GA4 number is genuinely and correctly lower than 140: (1) Calls that never touched the website — anyone who tapped "Call" on Rivertown's Google Business Profile / local pack, or dialed a number seen on a truck or a directory, is invisible to GA4; GA4 only counts tel: link clicks on the site. (2) A tap is not a connected call, and not every visitor is measured — GA4 counts the click, not the answered conversation, and only for consented, non-blocked visitors. The missing calls can be seen in Google Business Profile insights (which report calls from the profile) and in dedicated call-tracking software; the honest total is GA4 plus Profile insights plus the office log — never GA4 alone. Nothing is broken.

Exercise 28.19

Trust the direction/trend — a rise from ~900 to ~1,300 organic sessions is a real, meaningful increase, and month-over-month comparisons of like periods are what GA4 is good for. Don't over-read the exact figure — the true number is almost certainly higher (blocked/declined/unfired visits are missing) and fuzzier (some sessions modeled, some "users" one person on two devices, some data thresholded). Phrase it as magnitude and trend, not false precision: "Organic sessions rose roughly 40% month over month, from about 900 to about 1,300" — never "organic drove exactly 1,284 sessions." Round, and report the change, not the decimal.

Exercise 28.21

(Process/audit solution.) In Reports → Acquisition → Traffic acquisition, set the primary dimension to Session default channel group and filter to Organic Search; read Sessions, Engaged sessions, and Key events for the last 28 days. What this baseline tells you: the volume of SEO traffic, how engaged it was, and how much of it converted — a like-for-like number you can compare next month to answer "is SEO working?" What it does not tell you: which queries drove it (that's GSC / "(not provided)"), whether the counts are complete (consent/blockers/thresholding make them a floor), or whether conversions became revenue (that's the CRM + Chapter 39). It's a starting baseline, not a verdict.

Exercise 28.23

(Process/audit solution.) In Explore, create a segment defined as "Sessions where Session default channel group exactly matches Organic Search," name it (e.g., "Organic sessions"), and apply it to a free-form exploration with Landing page as the row dimension and Sessions / Engaged sessions / Engagement rate / Key events as values. What you can now see that standard reports made awkward: organic behavior and conversions by landing page in one view, with the freedom to add second dimensions (device, new vs. returning) and reuse the same segment across every future exploration — instead of re-filtering (and risking inconsistent filters) each time. Building the segment once is the habit that makes GA4 fast to work.

Exercise 28.25

• (a) Myth. GA4 bounce rate does not affect rankings — Google doesn't use your Analytics data to rank.
• (b) Myth. GA4 never shows the organic query ("(not provided)," 2011); that's Search Console, and even it doesn't tie a query to a specific visit.
• (c) Myth. Data-driven attribution is the best available model, not the truth — a black box needing enough data.
• (d) Myth. In GA4 a pageview is not special — it's an event (page_view) like any other.
• (e) Myth. Google has stated it does not use Google Analytics engagement data as a ranking signal.

Exercise 28.27

Policy problem: Google Analytics's terms prohibit sending personally identifiable information (PII) — names, emails, phone numbers — into GA4; violating this can get your data deleted or your account terminated. Privacy problem: it processes and transmits identifiable personal data (often without a lawful basis or proper consent), exposing the business to GDPR/CCPA-style risk (§28.7, Case Study 28.2). Correct place: identify who the lead is in the CRM or booking/scheduling system, which is built to hold personal data lawfully. In GA4, measure only that a lead happened and what category/value it was — aggregate behavior, never a back-door customer database.

Exercise 28.29

When a visitor denies consent and Consent Mode is active, GA4 sends only limited, cookieless pings (or nothing) — no persistent identifier, sharply reduced data. Google then models the resulting gap: statistically estimating the conversions and behavior it was not allowed to directly observe. That's the meaning of "a portion of what GA4 reports is modeled, not counted" — some of the numbers are Google's best estimate of the unmeasured, not a tally of observed events. This makes disclosing the funnel of loss important in a report because your stakeholder should know the figures are a modeled floor shaped by consent and blocking — directionally useful, but not a precise census — so no one builds a decision on a false sense of completeness.

Exercise 28.31

(Example — other valid answers exist.) A good fourth conversion for a home-services business is a maintenance-plan / membership enrollment (recurring revenue, distinct from a one-off form or booking). Capture it as a key event on the enrollment-confirmation step (or the enroll-button click), using a custom or recommended event — and, critically, no PII in the parameters (identify the member in the billing/CRM system, not GA4). It proves genuine interest in a high-value recurring product and lets you see which organic pages drive it. It doesn't prove the enrollment completed, was paid, or will renew — that lives in the billing system. (A lighter alternative: a lead-magnet file download — a "furnace maintenance checklist" PDF, captured via enhanced measurement's file_download — a top-of-funnel micro-conversion worth far less than an enrollment, which you should weight accordingly.)

Exercise 28.32

If Rivertown's booking runs through a third-party scheduling widget embedded in an iframe from a different domain, the booking-confirmation step may happen on that other domain, outside your GA4's default scope — so the confirmation event may never fire in your property, silently under-counting or missing bookings entirely. Related traps: the visitor can look like a new "user" when they cross domains (breaking attribution), and the widget vendor's own tracking is not yours. Flag to a developer before trusting the number: whether cross-domain measurement is configured for the widget's domain (so the session isn't split and the confirmation is captured), whether the confirmation step exposes a URL or event GA4 can see at all, and — as a fallback — whether the vendor can send a server-side or callback event on a completed booking. Verify a test booking appears in DebugView end to end before reporting bookings as a conversion.

Exercise 29.1

A KPI (Key Performance Indicator) is a small, deliberately chosen set of metrics, each tied directly to a business goal and capable of driving a decision. The one-sentence test that separates a KPI from "just a number": would moving this number change what you do next? If a metric can rise or fall and no business decision changes as a result, it is not a KPI — it is diagnostic detail (yours) or decoration (a vanity metric). The two words carry the definition: key (there are only a handful) and performance (it tracks progress toward the goal, not how busy you were).

Exercise 29.2 †

A baseline is the documented starting-point value of each KPI, captured at (or before) the start of the work and frozen. A report without one cannot honestly claim "improvement" because improvement is a comparison, and with nothing to compare against, "traffic is up" is a feeling, not a fact — you cannot prove a rise against a number you never wrote down. Even when the numbers genuinely rose, a missing baseline means you cannot say by how much, from what, or whether the rise beats the normal seasonal swing. Capturing and freezing the baseline on day one is the difference between a provable claim and an assertion the stakeholder must take on faith (and Case Study 2 shows what happens when they later stop).

Exercise 29.3

A vanity metric is a number that is easy to grow and pleasant to display but disconnected from any business outcome or decision. The test: what decision would this number change? — if none, it is decoration. The three the chapter singles out: total keyword count ("we rank for 10,000 keywords"), third-party Domain Authority (DA) / Domain Rating (DR), and raw impressions in isolation. Each can rise while the business is flat or falling, which is exactly why they mislead: they are true numbers that answer questions the business never asked.

Exercise 29.5

Reporting cadence is the rhythm of reporting matched to audience and altitude. The four intervals: weekly — audience you, altitude ground-level monitoring (the GSC ritual; catch problems, don't report); monthly — audience the owner/manager, altitude the KPI dashboard plus narrative (the core deliverable); quarterly — audience decision-makers, altitude trend and strategy (three months smooths the noise; budget check-in); annual — audience owner/CFO/board, altitude the business case (year-over-year, organic's share of revenue, the compounding story of Chapter 39). The higher up the ladder, the more the audience wants money and trend and the less they want tactics.

Exercise 29.7 †

A leading indicator moves first and predicts; a lagging indicator follows and confirms. Concretely: priority rankings are leading — a page climbs before it earns the extra traffic and conversions the climb produces — while organic conversions (and traffic, and revenue) are lagging, following the ranking movement by weeks or months, especially while terms sit on page 2 (which earns a fraction of page-1 clicks). Confusing them causes cancellations because an owner who expects conversions to move on the same clock as rankings sees "rankings up, revenue flat" in month three and concludes the program is failing — when that is the expected early shape. Reporting the two correctly, and explaining the lag, is what keeps the owner in their seat until the lagging line follows the leading one.

Exercise 29.9

Three concrete reasons GSC "organic clicks" and GA4 "organic sessions" disagree: (1) they measure different things — GSC counts a click on your listing in the Google results, on Google's side, before the visitor reaches your site; GA4 counts a session recorded by a tag that fires after the page loads; (2) GA4 misses anyone who clicked but bounced before the tag ran and anyone who declined tracking under a consent banner, so it undercounts; (3) GSC is Google-only, while GA4's "organic" also includes Bing and other search engines, so it counts sources GSC doesn't. Use GSC for impressions/clicks/position, GA4 for sessions/conversions, and label each number with its source. Forcing them to agree is a mistake because they are answering different questions — one measures the SERP, the other the site — and the honest move is to explain the gap, not hide or "reconcile" it.

Exercise 29.10 †

(a) Domain Authority does not belong on a value report because it is a third-party prediction, not a result: a tool vendor (Moz) invented it to estimate how well a site might rank, using a model Google does not use, know of, or consult. A rising DA is therefore not evidence Google ranks you better — it can be gamed, and it shifts when the vendor changes its own formula. Putting it on a report handed to an owner presents a vendor's guess as a business outcome. (b) Its one narrow, legitimate use is as a rough, comparative gut-check when prospecting links — "is this site roughly stronger or weaker than that one?" — which is where Chapter 22 (How Links Work) places it. Use it in your workspace for that; keep it off the value report.

Exercise 29.11

"We rank for 10,000 keywords" is a vanity metric because the count is inflated mostly by page-four-and-five positions for long-tail phrases almost nobody searches — impressions with no clicks, no intent, and no customers. The number rises simply by publishing more pages, so it measures activity, not success, and it can climb while leads and revenue fall (Case Study 2). Report instead the three numbers that connect to money: priority-term positions (are the terms that bring customers climbing?), non-branded organic clicks (are strangers actually arriving?), and organic conversions (are those arrivals becoming leads?).

Exercise 29.13

Report on the same date and in the same format every month because predictability is trust, and trust is the entire currency of a reporting relationship. A stakeholder who reliably receives a clean one-pager on the third of every month — wins and losses alike — comes to depend on it, and a program the owner depends on is a program that survives the quarter where results wobble. Erratic reporting, by contrast, reads as hiding even when it isn't: a skipped month or a suddenly different format makes an owner wonder what changed and why, and that suspicion does more damage than a flat number ever would. Consistency also lets the owner learn to read the report, which compounds their confidence over time.

Exercise 29.15 †

Everything on FIGURE E.29a is a vanity metric, so the report is true but useless. Keywords ranked (6,200 → 11,800) counts long-tail page-four terms nobody searches; Domain Authority (19 → 27) is a third-party prediction Google does not use; impressions (180k → 520k) without clicks can even mean the site now appears for irrelevant queries. None connects to the business, and the caption "SEO is clearly working" is asserted, not shown. Rebuild it around the five KPIs against a frozen baseline: non-branded organic clicks, organic conversions (leads/sales), priority-term positions, indexed pages, and Core Web Vitals status — each shown this month / last month / baseline — plus the traffic → leads → revenue narrative (§29.5) stated as organic-attributed, not caused. Then apply the test to every remaining chart: what decision would this number change? If none, it comes off the page.

Exercise 29.17 †

This is a normal in-progress month, reported honestly. The wins are real and leading (non-branded clicks +28%, priority terms on page 1 up from 3 to 5); the leads are essentially flat (118 vs. 120) because conversions lag rankings; the new comparison guides flopped (an intent miss — Chapter 3 — worth fixing, not hiding); and the one down week was a core update, not you, and it recovered. The plain-language sentence to the owner: "More of the right strangers are finding you on Google — non-branded traffic is up 28% and we now hold page one for five of our priority terms — leads are steady this month and should follow as those terms climb; one guide format missed the mark and we're re-pointing it." The adjustment: re-map the comparison guides toward the intent the searchers actually have (likely transactional/service), and keep the priority-term momentum.

Exercise 29.19

Plain-language rewrite: "Almost half again as many people saw Rivertown in Google's results this month for searches that weren't your name — and on the terms we're targeting, you moved up from around the middle of page two to the bottom of page one. The same share of them clicked as before, because the headlines Google shows still need work — that's the next fix." The rewrite trades every jargon term (impressions, MoM, average position, tracked corpus, CTR, title-tag remediation) for what it means to a home-services owner: how many strangers saw you, how far up you moved, and why clicks haven't risen yet — with the next action named.

Exercise 29.20 †

Reply, leading with leading indicators framed against the curve you set at the start: "Here's exactly where we are. Non-branded impressions are up 40%, and three priority terms — including 'furnace repair Cedar Hills' — moved from page 3 to page 2 this month; indexing is cleaned up. These are the signals that come before traffic and revenue, which is the pattern we discussed up front: rankings move first, the money follows as those terms climb toward page one. Revenue is genuinely flat so far — I won't pretend otherwise — and that's the 'valley' we expected around now." Lead with rankings and non-branded impressions; frame the lag honestly; point to the pre-agreed curve. What you refuse to do: promise a ranking or a specific date to save the account. If you never had the long-game conversation at the start, this email is the bill for that omission — which is exactly why you have it, in writing, before month one.

Exercise 29.21

Before concluding "SEO is failing," check the non-catastrophe explanations for a 15% conversion drop: (1) Measurement — did a tag break, a form change, or a consent-banner update stop recording some conversions? A tracking break looks exactly like a business drop. (2) Seasonality — is this a normally slow month for the business (weather, holidays, industry cycle)? Compare year-over-year, not just month-over-month. (3) Attribution/channel shift — did conversions move to another channel (more branded/direct as awareness grew), so organic's share fell while total held? (4) A short month or fewer business days, or a one-off (a phone line down, a promotion ending). (5) A real SEO cause — a ranking or traffic drop upstream (check GSC), possibly a core update. Only after ruling out measurement, seasonality, and attribution do you escalate — and you report the investigation, not a premature verdict.

Exercise 29.23

To the CFO, separate the confident claim from the hedge. Confidently: organic search was attributed (by GA4, last significant click) with N leads — calls, forms, bookings — a number you can count cleanly, and those leads are associated with roughly \$X in booked work based on the business's own close rate and job values. Hedge: you cannot claim organic caused all of it — attribution is a model that credits the last click even when a review, a referral, or a truck sighting did the real convincing, and offline closes and consent-declined visits mean the count is a floor. The exact phrase: "organic-attributed revenue," never "organic-caused." Report leads more confidently than revenue, and treat the dollar figure as directional, not audited. (The rigorous ROI model — cost, net, break-even — is Chapter 39.)

Exercise 29.24 †

(Guided — numbers vary by site.) The deliverable is a dated, frozen file holding roughly seven numbers: from GA4, last complete month's organic sessions and each defined conversion (calls/forms/bookings/sales); from Search Console, last three months' clicks, impressions, average position, and indexed-vs-not-indexed page counts. The one sentence on why you must not edit it later: because a baseline only proves change if it stays fixed — the moment you "update" it, you lose the honest starting line, and every future "improvement" becomes unverifiable. A learner who captures the numbers and protects them from later editing has understood §29.1; one who records them in a live dashboard that overwrites itself has not made a baseline at all.

Exercise 29.25

(Guided.) The deliverable is a shareable Looker Studio link showing four scorecards — non-branded clicks, priority-term average position, organic sessions, organic conversions — each with month-over-month comparison enabled and each labeled with its source (GSC or GA4). The one thing the auto-dashboard cannot do that you still must: interpret it — explain the why behind a movement, flag a tracking break versus a real drop, translate the numbers into the owner's language, and put the misses next to the wins. A dashboard automates the display of data; it never automates the judgment that turns data into an honest report. (A good answer also notes that the numbers on it will not match across the two sources — and that labeling each source is the honest fix, not forcing agreement.)

Exercise 29.27

(Guided.) A strong answer selects 15–20 priority terms that are (a) commercially meaningful — terms a paying customer actually types on the way to buying, not just any term you appear for; (b) realistically winnable given the site's authority (a mix of a few competitive head terms and several achievable long-tail/local ones); and (c) agreed with the stakeholder as the ones that matter. The justification is the whole point: you track these and not the thousands of others because a curated set is reportable and actionable — you can watch each move, diagnose the ones that stall, and roll them into a share of voice — whereas "all 10,000 keywords" is noise no one can act on. What makes a term "priority" is business value × relevance to intent, not search volume alone.

Exercise 29.29 †

Response: "I won't leave out the flat leads or the posts that flopped, and here's why it's the right business call, not just the honest one." What you will do: report the genuine leading-indicator wins clearly (they're real and they matter) and the flat leads and the flopped posts, with the adjustment for the miss. What you won't do: lead with Domain Authority and keyword count (vanity metrics that connect to nothing) or bury the bad news. The business reason: a stakeholder who later discovers a hidden bad month — and they always eventually do, usually by checking the bank account (Case Study 2) — stops trusting every report, including the honest good ones, and cancels; whereas a stakeholder who sees you report a miss straight, with a plan, trusts the wins more. Honesty is not just ethics here; it is the only thing that funds year three. Hiding one month to survive this one forfeits the relationship that survives the year.

Exercise 29.31

(Model rewrite — numbers illustrative.) Turn FIGURE E.29a into a one-page KPI report: Headline — "Organic search brought ~140 new leads last month, up from ~95 at baseline; new-customer (non-branded) traffic is up 32%." The five KPIs (this month / last / baseline): non-branded organic clicks (2,300 / 2,050 / 1,700); organic conversions (140 / 128 / 95); priority terms on page 1 (6 of 20 / 4 / 2); indexed pages (410 / 395 / 380); mobile Core Web Vitals (needs improvement / poor / poor). What didn't work: "the three new 'ultimate guide' posts drew ~50 clicks total — wrong intent; re-pointing next month." Owner sentence: "More strangers are finding us and becoming leads, steadily and as expected; the trend is up on every number that turns into a sale." Fine print: sources labeled (GSC/GA4); conversions are a floor (consent); no ranking promised. Note the deletions: keyword count, DA, and raw impressions are gone — because none would change a decision.

Exercise 29.33

(Guided — the reader's own one-pager.) A strong deliverable is a single page that: opens with the outcome the owner feels (leads and/or revenue, with the trend); shows the five KPIs against the reader's frozen baseline, each labeled with its source; includes at least one honest "what didn't work" with an adjustment; closes with a plain-language sentence a non-specialist understands and an honest limits note (attribution is a model; conversions are a floor; no ranking promised). Grade it on legibility and honesty, not polish: could a busy owner who has never heard the word "impressions" read it in two minutes, understand it, believe it, and know what happens next? If a vanity metric (keyword count, DA) appears anywhere on the page, it fails the §29.2 test.

Chapter 30 — Worked Solutions

Worked solutions to the daggered (†) and odd-numbered exercises. (Other items are for open discussion or depend on the reader's own site; where an item is site-specific, the method and the shape of a good answer are given.)

Exercise 30.1

Any four of: location (distance is a local ranking signal; the biggest factor), personalization (your prior activity, especially visits to your own site), device (mobile vs. desktop SERPs differ in layout and emphasis), time / SERP volatility (rankings flicker as Google recrawls and re-evaluates), language, and the SERP features around your result (an AI Overview, local pack, or snippet changes what a position is worth). The point: rank is a distribution across these, not a single value.

Exercise 30.2 †

Rank tracking — monitoring where your pages appear for chosen keywords over time; good for trends from a fixed vantage point, not a single true rank. SERP volatility — the normal day-to-day fluctuation of rankings from Google's continual re-evaluation and updates. Personalization — Google's tailoring of results to an individual by location, language, device, and (limited) prior activity. SEO competitor — any site that ranks for a query you want, whether or not it's a business rival.

Exercise 30.3

A keyword gap is query-level and site-scale: specific keywords competitors rank for that you don't rank for at all (e.g., a store has no page ranking for "waterproof hiking boots"). A content gap is topic/coverage level, often read inside an existing page: subtopics a ranking page covers that yours omits (e.g., your boot page never mentions sizing or waterproof ratings). Keyword gaps point at missing pages; content gaps point at missing topics or sections.

Exercise 30.5

The three sets and their strategies: local rivals — win the local pack (Google Business Profile, proximity, reviews; Chapter 25), not a content fight; directories/aggregators (Yelp, Angi, HomeAdvisor, listicles) — get listed and well-reviewed inside them rather than trying to out-rank them in organic; and publishers/platforms (This Old House, YouTube, Reddit) — compete on genuinely expert, complete content, where first-hand experience (E-E-A-T) is your edge.

Exercise 30.7

A crawler tool is software that fetches a site's pages by following its links (like a search engine's crawler) to inspect them at scale — titles, status codes, canonicals, redirects, depth. It is a different category from an all-in-one suite: a suite is mainly a keyword/backlink/competitor database built from the vendor's own web crawl and third-party data, whereas a crawler inspects your site's technical structure directly. Best-known crawler: Screaming Frog (the SEO Spider).

Exercise 30.9 †

Two reasons not to panic: (1) SERP volatility — a 4→7 move overnight is within normal flicker for many terms and may reverse by itself; (2) the reading is a single sample from one vantage point (and possibly personalized/localized), not a trend. The one thing to check first: the trend over weeks, and whether impressions/clicks in Search Console actually moved — if traffic is flat and the trend line is steady, the one-day "drop" is noise, not signal. Only a sustained, multi-week decline with a traffic drop warrants action.

Exercise 30.11

Two reasons "average position across all keywords" is near-meaningless: (1) it blends money terms with thousands of low-value, low-position terms, so it moves without the business moving (a vanity metric, Chapter 29); (2) "position" is itself an average across locations/devices/personalization, so you are averaging an average. A better headline: organic conversions (leads/calls/bookings) and their trend, supported by priority-term rankings and share of voice, not a single blended position number.

Exercise 30.13 †

A real HVAC company can out-rank publishers on "how to relight a furnace pilot light" because the publishers' pages are often generic and second-hand, while a working contractor can write from direct, hands-on experience — the "Experience" in E-E-A-T (Chapter 5) — with specifics, safety cautions, and photos a generalist can't match. The edge is genuine experience, provided the page is also as complete as the incumbents (close the content gap) and the site can be crawled/indexed and has some authority. It is not guaranteed — Google still decides — but the fight is winnable on merit.

Exercise 30.15

Because a keyword-gap list shows only what competitors rank for, not what is valuable to you or winnable by you. Some of the 380 terms bring no customer; some are owned by national brands you can't beat; some are "gaps" because the topic is a dead end. Each must pass Chapter 7's opportunity = value × winnability test before earning a page. The list is a set of candidates; writing all 380 produces the thin, dead pages a content audit (Chapter 12) later has to prune.

Exercise 30.17 †

Run a page-level content-gap analysis: open the two or three pages outranking you for the term and read them section by section, listing every subtopic, question, and format they cover that your page doesn't (cost breakdowns, DIY-vs-pro, permits, signs, timing, brands, financing, etc.); cross-check the "People Also Ask" box for the buyer's real questions. The deliverable is a specific, itemized to-do list — the sections your page must add to be genuinely as complete as the winners (which you then execute via Chapter 9's comprehensiveness craft, keeping the intent-matched title and internal links). It makes Chapter 1's vague "be more complete" concrete.

Exercise 30.19

The problem is keyword cannibalization (Chapter 12): two of your own pages targeting the same query split your relevance, authority, and click signals, so neither consolidates enough to reach page one. The rank tracker's clue is exactly that both pages hover around positions 12–18 and trade places — Google can't decide which is the right answer, so it ranks neither well. The fix is to merge them into one strong page (or clearly differentiate their intents), then redirect.

Exercise 30.20 †

(Site-specific — method and good-answer shape.) Good work product: a ten-row table of priority queries (each tied to a goal, not just high impressions), each with last-3-months and prior-3-months average position and a label (up / down / flickering). The two follow-up sentences should (a) for the most improved term, propose doubling down — e.g., strengthen internal links or add the striking-distance content that's working; (b) for the most declined term, propose diagnosing before reacting — check whether it's a real multi-week trend with a traffic drop (act) or flicker (wait), and whether a competitor changed. Full credit rewards choosing priority terms and reading direction, not chasing single numbers.

Exercise 30.21

(Site-specific.) A strong answer lists the actual top-ten results and tags each as rival (a direct business competitor), directory/aggregator (Yelp, Angi, a listicle), or publisher/platform (a magazine, YouTube, Reddit). The insight to reward: for most commercial/local queries the top of the SERP is aggregators and publishers, not business rivals — which reframes the strategy (win the local pack + be listed in the directories, out-expert the publishers) rather than "beat the company across town."

Exercise 30.23

(Site-specific.) Any three findings a crawl surfaces that browsing hides: duplicate or missing title tags/meta descriptions; pages returning non-200 status codes (404s, 500s); redirect chains; stray noindex directives; orphan or very deep pages; broken internal/external links; missing alt text. The learning to reward: these are bulk, structural facts visible only to a crawler, and they map to Chapters 14 (indexing), 15 (architecture), and 21 (redirects) — and they feed the audit of Chapter 38.

Exercise 30.25 †

(Choice will vary; judge the reasoning.) A good answer names three competitors by query cluster, not by rivalry: e.g., for a transactional/local term ("plumber near me") a directory or local-pack rival; for a commercial term ("tankless water heater cost") a contractor blog or review publisher; for an informational term ("why is my water heater leaking") a home-improvement publisher or YouTube. Each is chosen because it actually holds the SERP for that cluster — verified by searching the term, not assumed from industry knowledge. The key point: different clusters have different competitors.

Exercise 30.27

Pursue: "furnace repair [your city]" — high value (ready-to-hire local searcher), core to the business. Maybe: "HVAC financing bad credit" — could be valuable (a real customer concern and a content-gap section) but check intent and winnability; may be a section on a page rather than its own page. Ignore: "commercial dehumidifier for grow rooms" — irrelevant to a residential home-services company; a "gap" that is correctly a gap. The lesson: relevance and value filter the gap list before winnability even enters.

Exercise 30.29

Pursue the local chamber, the supplier's installer locator, and the regional newspaper's home section — relevant, authoritative, earnable (via membership/citation, a dealer relationship, and a genuinely citeable asset or story). Ignore the nine low-quality overseas directories — irrelevant and low value. Never buy any of them (and especially not link-network placements): buying links to pass PageRank violates Google's guidelines and is a detectable, retroactively-punished liability (Chapter 22, §22.6). A backlink gap is a map of links to earn, not to purchase.

Exercise 30.31 †

The framing "The 7 Best SEO Tools, Ranked" implies an objective, universal ranking that doesn't exist: the tools disagree with each other on basic numbers (all estimate data only Google holds), "best" depends entirely on your work, budget, and what you'll actually use, and such posts are frequently affiliate-monetized (the author earns a commission on the tools they rank highest). A more honest title: something like "How the major SEO tools differ, and how to choose one for your situation" — comparative and situational, disclosing any affiliate relationship, and claiming fit, not best.

Exercise 30.33 †

The honest explanation: there is no single real number because Google builds each results page per searcher — your rank tracker samples one declared location/device, Search Console reports a blended average across all your real impressions, and the paid suite estimates from its own crawl; all three are different, valid samples of a distribution, not disagreements about one fact. How to report it usefully: give the client a trend for their priority terms from a fixed, stated vantage point ("on mobile, in [city], over the last month"), pair it with Search Console's blended average for honesty, and — most importantly — walk it forward to traffic and conversions, which is what they actually care about. Truthful and useful: state the context, show the direction, tie it to money.

Exercise 30.35 †

A sensible Rivertown setup: track a curated set of priority terms (the service × city money terms across all five cities, the high-value commercial terms like "water heater replacement cost," and a few informational terms it's building authority on) — per city (Rivertown, Cedar Hills, Northgate, Westbrook, Millhaven), on mobile, checked weekly but reviewed as a monthly trend, and reported as direction plus the priority-term movements that feed the KPIs of Chapter 29. A single metro-wide average would mislead the Delgados because Rivertown might be #2 in Cedar Hills and invisible in Millhaven; the average (say, ~9) describes neither city and hides exactly the per-market reality the five-location strategy lives or dies on. Connect to Chapter 29: report priority-term rankings and share of voice, always walked forward to calls/forms.

Exercise 30.37 †

A competitive rewrite of Rivertown's listing. Title tag (aim ~50–60 characters, front-load the query and a differentiator): e.g., "Water Heater Replacement Cost in [City] (2026) | Rivertown". Meta description (preview the answer the winner promises — a non-ranking element that earns the click): e.g., "What a new water heater really costs — tank vs. tankless, unit vs. labor, permits, and when to replace. Licensed local plumbers, honest quotes." What a better snippet can do: lift click-through at a given position by matching intent and previewing value (the meta description is ad copy for your listing, Chapter 9). What it cannot do: move the ranking by itself — the meta description is not a ranking factor, and the title's effect on ranking is modest; the position still depends on relevance, comprehensiveness, and authority (Chapters 3, 9, 22). Better snippet = more clicks from the rank you have, not a higher rank.

Exercise 31.1

A category page (product listing page / PLP) lists many products in a group and is the right answer to a browse/commercial query for a class of products — "backpacking tents," "women's hiking boots." A product page (product detail page / PDP) is the page for one purchasable item and is the right answer to a specific/transactional query for that item — "Big Agnes Copper Spur UL2." One matches "show me a shelf of options"; the other matches "I want this exact box."

Exercise 31.3 †

A parameter URL is a URL that carries query-string parameters after a ?, such as /tents/backpacking?capacity=2p&season=3-season&sort=price. Each key=value pair typically corresponds to a filter or sort choice. A single category can generate tens of thousands of them because facets combine multiplicatively: with, say, 4 capacity × 2 season × 12 brand × 5 price × 4 weight × 6 color values, that is $4 \times 2 \times 12 \times 5 \times 4 \times 6 = 11{,}520$ filter combinations — before multiplying by sort orders and per-page views, which pushes one 180-product category toward ~138,000 crawlable URLs. Each is, to a crawler, a distinct page it may fetch and try to index, even though almost none corresponds to a real search or a distinct set of products.

Exercise 31.5

Out-of-stock handling is a store's deliberate, written policy for what happens to a product URL when the item is unavailable — chosen so you neither destroy accumulated ranking equity nor hoard dead pages. The three lifecycle situations it must cover: (1) temporarily out of stock (keep live at 200, mark OutOfStock, offer alternatives/notify-me); (2) seasonal (keep the URL live year-round; don't delete and rebuild each season); (3) discontinued/permanent (301 to a successor or relevant category if it has equity, or let it 404/410 if genuinely dead).

Exercise 31.7

The argument: category pages match the browse queries that carry the most non-branded commercial volume ("backpacking tents"), and they collect the most internal-link authority because they're linked from the main navigation on every page — so they are simultaneously the highest-opportunity and the most-authoritative pages on the store. Yet most are left as bare product grids. The single most common reason such a page fails to rank despite that authority is that it has no unique, intent-matching content — no descriptive title/<h1>, no short useful intro, no curated element — so it expresses almost no relevance for Google to rank it by. High authority, near-zero expressed relevance.

Exercise 31.8 †

From Google's point of view, a product page carrying the manufacturer's stock description is one more copy of text that already appears, word-for-word, on dozens or hundreds of other retailers' pages. It contributes no new information, so there is no reason to rank it above any other copy — and often a strong reason to rank it below the manufacturer's own page and the highest-authority retailers. "Information gain" is content a shopper genuinely cannot get from the boilerplate. For a backpacking tent, that would be things only a store that uses the product can say: how it pitches in real wind, whether a 6'2" hiker fits diagonally, how it compares to the two obvious alternatives at the same weight, what the fly does in sustained rain, who should buy it and who should look elsewhere — plus honest fit/spec notes and real customer reviews. That is unique, useful, and exactly what the model-name searcher wants.

Exercise 31.9

They "don't compose" because they operate at different stages: robots.txt controls crawling, while noindex is an instruction Google can only obey if it reads the page. If you Disallow a parameter pattern in robots.txt, Googlebot never fetches those URLs — so it never sees the noindex you placed on them, and the tag can't take effect. The exact wrong outcome: the pages you meant to remove stay in the index (sometimes as bare, description-less listings if they're linked from elsewhere), and Google is now blind to your removal instruction. The correct order is: allow crawling and use noindex first (so Google reads and honors it and de-indexes the pages), then add a robots.txt block later, only to stop wasting crawl once the pages are already gone.

Exercise 31.11

Three benefits, all real: (1) reviews add unique, continually-refreshed content to a page that would otherwise be static and templated, at zero marginal writing cost; (2) they grow long-tail relevance, because real buyers write in the exact words other buyers search ("runs narrow," "great for a rainy trip"); (3) they demonstrate trust — testimony from outside the store, an E-E-A-T signal (Ch 5) — and, via review schema (Ch 18), can earn star rich results that lift click-through. The one rule that makes all three valid: the reviews must be genuine. Fabricating, buying, or censoring out the negative ones violates Google's review-snippet policies and consumer-protection law, and it destroys the very signal that gave reviews their value.

Exercise 31.13

Two reasons it over-reacts: (1) there is no general duplicate-content penalty — Google consolidates and selects among duplicates rather than punishing an ordinary catalog — so the premise is false; and (2) noindex-ing every such product page would remove the store's entire chance of ranking for its brand-and-model long-tail queries, throwing away real revenue to solve a non-problem. What to do instead: add unique, expert copy and real reviews to the important products (the 80/20), consolidate color/size variants onto canonical URLs, let reviews/Q&A differentiate the long tail, and prune only the genuinely valueless pages. Triage, not a blanket block.

Exercise 31.15 †

The strategic error is entering the wrong page type into the contest. "Running shoes" is a browse query — Google ranks category pages and buying guides for it, not individual product pages — so "optimizing the product pages harder" is optimizing pages that can never win that query regardless of effort. The product pages already ranking for specific model names are doing exactly the right job (winning the specific long-tail). The page type that should target "running shoes" is a category page: a well-titled, intent-matching listing of running shoes with a short useful intro, internal links to subcategories ("trail," "road," "stability") and hero products, and ideally a curated element. Match page type to intent before touching optimization.

Exercise 31.16 †

The cause is unmanaged faceted navigation generating parameter URLs at scale (the ?sort=/?filter= URLs Googlebot is spending its crawl on). The ordered fix: (1) Allow crawling of those URLs and apply rel="canonical" on sort/view variants pointing back to the base category, plus noindex on the thin filter pages — so Google can actually read these instructions. (2) Promote the handful of genuinely high-demand facets (e.g., "trail running shoes") to real, static, indexable subcategory pages with unique content and clean URLs. (3) Wait for Google to re-crawl and drop the noindex'd pages; watch the indexed count fall toward the real product count. (4) Only then add a targeted robots.txt Disallow on the specific worthless parameters to stop wasting crawl going forward — carefully, so it can't catch the real landing pages. Doing robots.txt first would blind Google to the canonical/noindex and solve nothing.

Exercise 31.17

Two problems. First, an intent/UX mismatch: a 1,500-word keyword-stuffed block above the grid pushes the actual products below the fold, which fights the browse intent (the shopper wants to see tents, not read an essay) and drives the hard bounce. Second, keyword stuffing is not what earns the ranking anyway — comprehensiveness and relevance are, and stuffing signals low quality. Better structure: a short (two-to-three-sentence) intent-matching intro at the top establishing what the collection is and who it's for; the product grid immediately visible; optional deeper content (a compact buying-orientation block, an FAQ, or a "how to choose" section) below the products for the shoppers and crawlers who want it; a descriptive title and <h1>; and internal links to subcategories and the relevant buying guide.

Exercise 31.19

The mistake was returning a 404 for a temporarily out-of-stock product. A 404 tells Google the page is gone, so Google drops it from the index and the accumulated rankings and links evaporate — which is why the rankings had cratered by the time the tent came back. Temporary stockouts should never 404 (or redirect, or noindex). Correct handling: keep the page live at 200 OK, mark availability as OutOfStock in Product schema, and make the page useful anyway — show related/alternative products, offer a "notify me when back in stock," and keep the reviews and content. When inventory returns, the page (and its rankings) are intact.

Exercise 31.21 †

(Guided — results vary by store.) The deliverable is one interpretive sentence naming a duplication symptom. Example: "A distinctive sentence from our best-seller's description returns 40+ other stores using the identical text — that page is manufacturer boilerplate, which is why it's outranked by higher-authority retailers running the same copy." If instead only your page returns the sentence, that's the good case: "Our description is unique on the web, so the page competes on its own content rather than as one interchangeable copy." The point is to see the duplication from Google's side, not to fix it yet — the fix is unique copy + reviews on the important products (§31.2, §31.4).

Exercise 31.23

(Guided — results vary.) The deliverable is the top-five internal search terms and any zero-result queries, each with a one-sentence read. Example reads: a top term with strong volume but no dedicated landing page ("ultralight tent" searched heavily, no such category) → a category/content gap worth building. A zero-result term for something you do sell under another name ("puffy jacket," you list "insulated jacket") → a synonym-mapping problem hurting both internal search and organic targeting. A zero-result term for something you don't carry ("packable down vest") → a product gap or a content idea. A conceptual zero-result query ("waterproof vs water resistant") → a content opportunity, not a product. The theme: your search box is first-party keyword research from your most qualified audience.

Exercise 31.25 †

The lines that indict faceted navigation are "Crawled – currently not indexed" (210,000) and "Duplicate, Google chose a different canonical" (140,000) — a store with ~10,500 products should not have hundreds of thousands of crawled-but-rejected and duplicate URLs; that volume is filter/sort permutations Google fetched and declined to keep. The healthy line is "Alternate page with proper canonical tag" (25,000) — that is canonicalization working as intended (variant pages correctly pointing at their canonical), not a problem to fix. First move: confirm the parameter URLs are crawlable and carry canonical/noindex correctly, canonicalize sort/view variants to their base category, noindex the thin filter pages, and promote the few high-demand facets to real pages — then consider a targeted crawl block. The 5,000 noindex exclusions are worth a glance to confirm none are pages you actually wanted indexed.

Exercise 31.27 †

A model rewrite (yours may vary in wording): - (a) Title tag: Backpacking Tents — Ultralight to 4-Season | Summit Gear (states the class and the range; matches browse intent; brand last). - (b) <h1>: Backpacking Tents — or, better, Backpacking Tents: Ultralight, 2-Person, and 4-Season. - (c) Intro (short, keeps products near the fold): "Every backpacking tent here is chosen for the trail — light enough to carry all day, tough enough for real weather. Filter by capacity, season, and weight to find your fit, or start with our field-tested favorites below. Not sure where to begin? See our guide to choosing a backpacking tent." (Two to three sentences; useful; doesn't bury the grid.) - (d) Three internal links to add: to the subcategories "1-Person Tents," "2-Person Tents," and "4-Season Tents"; to two or three hero products; and to the "How to choose a backpacking tent" buying guide. (Makes the page a real hub — §31.1, Ch 15.)

Exercise 31.29

"Coffee grinder" is a generic head term dominated by Amazon and big retailers — an unwinnable fight for most specialists (the Amazon paradox), so it's the wrong target. Four winnable long-tail queries and their page types: "burr grinder for espresso" → category page; "quiet burr grinder for an office" → category (or a curated landing page); "Baratza Encore review" → product page (or a review/content page); "blade vs. burr grinder" and "how to choose a coffee grinder" → informational guide. The pattern: concede the head term; win the specific commercial long-tail with tight category pages and the pre-purchase informational queries with expert content (watching for AI Overviews on the informational ones).

Exercise 31.30 †

Classification and the single most urgent action: - packable down vest (312 searches, 0 results) → product/category gap with strong demand. Most urgent action — this is the one: 312 qualified shoppers a period are searching for something you return nothing for. Either stock/surface a packable down vest or, if you carry one under another name, fix the mapping immediately. - puffy jacket (280, results shown) → likely a synonym the site already handles ("insulated jacket"); verify the results are actually relevant and the synonym is mapped for organic targeting too. - merino base layer men (190, results) → healthy demand with results; confirm there's a strong dedicated category/landing page for it. - waterproof vs water resistant (140, 0 results) → a content opportunity (a short explainer/buying-guide), not a product gap. - size chart (600, results) → a UX signal: shoppers can't find sizing easily. Make the size chart more prominent on product pages (a findability fix, not an SEO page).

Exercise 31.31

Two bundled myths. (1) "Duplicate content is a Google penalty" — false for ordinary catalogs; Google consolidates and selects among duplicates (keeps/ranks one, sets the rest aside), it doesn't demote you for having them. Only deceptive, scaled duplication (scraped or spun content) is a guidelines problem. (2) "You must write 1,000 unique words on every one of 20,000 products or be demoted" — false on both counts: Google never set a word-count requirement, and mass-padding 20,000 pages is itself the "scaled content abuse" quality systems target. The truth: give unique, expert copy to the important products; use structured specs + reviews/Q&A to differentiate the long tail; prune the valueless. Usefulness, not length; triage, not a blanket rewrite.

Exercise 31.33 †

The few things from this chapter that genuinely apply to Rivertown's ~25-SKU parts/filters store: (1) write unique short copy on the filter and thermostat pages — which size fits which system, how often to change a filter — information gain a technician can supply, not manufacturer boilerplate (§31.2); (2) add Product schema (price/availability) to the ~25 SKUs (Ch 18); (3) keep a temporarily out-of-stock filter live with "notify me," not 404'd (§31.5); (4) don't let filter-size/brand facets spawn parameter-URL junk (§31.3) — trivial to control at 25 SKUs. What does not apply: category-page strategy at scale, the Amazon paradox, industrial faceted navigation, and catalog pruning — Rivertown has no catalog to speak of. Rivertown's real SEO effort belongs where it actually competes: local SEO (the local pack, Ch 25) and its service×city pages (Ch 33). One sentence: give the parts store correct-but-minimal hygiene and spend the real budget on local.

Exercise 32.1

The content funnel is a model that maps content to the stages a buyer passes through, from first awareness of a problem to the decision to buy. Its three stages: ToFu (top of funnel) — the awareness stage, mapping to informational intent ("what is field service management," "how to reduce technician drive time"); MoFu (middle of funnel) — the consideration stage, mapping to commercial intent ("field service management software: a buyer's guide," "spreadsheet vs software for dispatch"); BoFu (bottom of funnel) — the decision stage, mapping to commercial/transactional intent ("Dispatchr vs FleetOps," "field service software pricing"). Volume falls and value rises as you descend.

Exercise 32.3 †

Product-led content teaches a job-to-be-done by showing the product doing it — use-case pages, "how to do X" workflow guides where the tool is the natural answer, template libraries, and free tools/calculators. It is the content arm of product-led growth (PLG) and sits near the bottom of the funnel (high intent, narrow reach). Example query: "how to cut technician drive time with route optimization." An integration page is built around the combination of your product and another named tool ("[Product] + [Tool] integration"), capturing sharp combined-intent commercial searches. Example query: "Dispatchr QuickBooks integration." Both convert well because the intent is specific and commercial; both must carry genuine, page-specific value or they slide into thin doorway content (§32.4, Ch 33).

Exercise 32.5

MQL = marketing-qualified lead: a lead that marketing judges interested and well-fit enough (by behavior — downloaded a guide, requested a demo — and by profile/ideal-customer fit) to be worth the sales team's attention. SQL = sales-qualified lead: a lead that sales has vetted and accepted as a genuine opportunity worth pursuing. The correct order: visitor → lead → MQL → SQL → opportunity → closed-won. The point of the distinction is that marketing and sales apply different bars, and SEO's contribution has to be traced across the whole chain — much of which lives in the CRM and sales' judgment, not in analytics.

Exercise 32.7

Google reads only the search intent behind each query, one search at a time — whether the person wants to learn, compare, or choose — not your internal "ToFu/MoFu/BoFu" labels, which are purely a planning convenience. The implication: when you assign a page to a funnel stage, the real question underneath is what does the person typing this query actually want right now? — and you verify it by reading the SERP for that query (Ch 3). If a keyword you filed as "BoFu" returns how-to explainers, you mis-read the intent, not the funnel. Build to the intent the SERP reveals, and let the funnel stage be just a summary of where in the journey that intent tends to sit.

Exercise 32.8 †

Because in B2B you stop counting searches and start counting who is searching. The ~50 people typing "Dispatchr vs FleetOps" are late-stage buyers actively weighing your product against a named competitor — the highest commercial intent there is — and the page can convert them at a rate an order of magnitude higher than any top-of-funnel guide, often into trials and sales conversations directly. The 40,000 visitors to a ToFu guide are mostly there to learn, not to buy; that traffic builds awareness and (maybe) a subscriber, but it does not close deals. B2B keywords are low-volume and high-value, and the money lives at the bottom of the funnel — so the strategist prioritizes the tiny-volume BoFu page because its pipeline contribution dwarfs the big-traffic ToFu page's. (Traffic and pipeline can point in opposite directions — §32.7.)

Exercise 32.9

A comparison page exists to help a buyer decide, which means its entire value depends on being believed at the moment of decision. A rigged "we win every row" comparison signals "marketing, not information" — buyers are not stupid, and the moment they sense the page is self-serving, they discount everything on it, including the true claims. So honesty is the mechanism: a page that concedes honestly ("if you need X, the competitor is genuinely better; here is where we win instead") earns trust exactly when trust closes the sale, while a dishonest one destroys the very thing it was built to create. Beyond the mechanism, a rigged comparison also risks Google's spam guidance and consumer-protection/advertising law around misleading claims. Fair comparisons convert; rigged ones are a liability.

Exercise 32.11

Publishing a hundred thin, AI-spun articles to "build topical authority" produces the opposite because coverage without depth is not authority — it is bloat. The mechanism: Google's Helpful Content systems (Ch 6) assess quality at the site level and are built to recognize content produced at scale with little added value; a mass of shallow pages signals exactly that, and can lower the site's overall quality assessment across the board. Authority comes from genuine depth, expertise, and usefulness accumulated over quarters and years — which is precisely why it is a moat once earned and cannot be faked with volume. Ten genuinely definitive articles beat a hundred shallow ones every time.

Exercise 32.13

In a long B2B cycle a single deal is touched many times over months (the Feb-to-Nov journey: a February organic ToFu guide → an April MoFu guide → a June "vs competitor" comparison → an August sales demo → a November signing that arrives via a direct visit or branded search). Last-click attribution credits only the final interaction before conversion — here the November branded/direct touch — so all three earlier organic searches that opened and advanced the relationship receive zero credit. Because the top and middle of the funnel do their work early and rarely appear as the last touch, last-click systematically undervalues them — and, applied to SEO, makes a program that started and advanced the deal look worthless. The honest fix is multi-touch attribution plus self-reported data, reported as a range (§32.5).

Exercise 32.15 †

The most likely cause is a program optimized for traffic rather than pipeline, publishing broad top-of-funnel content that pulls big informational volume but attracts readers, not buyers — the traffic and the qualified buyers were never the same people (§32.7; Case Study 2). Diagnostic checks: what share of the 60,000 visits lands on product-relevant / bottom-of-funnel pages, and what intent do the top-traffic queries carry (learning vs. choosing)? The two page types the company is almost certainly neglecting are the bottom-of-funnel commercial pages: comparison / "alternatives" pages (§32.2) and product-led / integration & use-case pages (§32.4) — the low-volume, high-intent pages that actually convert. The fix is to rebalance toward those, tie content to real buying intent, and change the metric to qualified pipeline.

Exercise 32.16 †

What happened: 300 near-identical, two-sentence "[Product] + [Tool]" pages generated from one empty template are thin, scaled doorway content (§32.4) — pages built for search with no genuine per-page value. A Google core / Helpful Content update (Ch 6, Ch 13) recognized the pattern and lowered the site's quality assessment, dropping rankings site-wide (the harm is site-level, not just per-page), which is why even unrelated pages softened. An honest version of an integration page contains real, page-specific value: (1) what the integration actually does (the specific data/workflow it connects); (2) who it's for and the specific problem it solves; (3) real setup steps and how it works; (4) honest limits — what it does not do yet; (5) a relevant call to action. The test: could this page only have been written by someone who understands that integration? If a find-and-replace of the tool name produces it, it's a doorway.

Exercise 32.17

The question to expect is some version of "How many customers — or how much pipeline — did that traffic produce?" A 60% traffic rise means nothing if it is top-of-funnel volume that never converts; in B2B, traffic and revenue can move in opposite directions. The founder should have led with the business outcomes: organic-influenced pipeline and qualified leads (MQLs/SQLs), demo/trial starts from bottom-of-funnel pages, and priority commercial-keyword positions — with traffic relegated to supporting context. Leading with a vanity metric (Ch 29) invites the "so what?" that gets a program defunded; leading with pipeline answers it before it is asked.

Exercise 32.19

The mistake is targeting bottom-of-funnel comparison and "alternatives" pages for a category almost nobody searches yet — those pages capture existing demand, and for a brand-new product in an unknown category there is little to no "[us] vs" or "[competitor] alternatives" search volume to capture. The skipped stages are the top and middle of the funnel: the company never built the awareness (ToFu, informational) and consideration (MoFu, commercial) content that would create category awareness and get the product into buyers' consideration sets in the first place. The BoFu tactic is powerful where demand exists and premature where it doesn't (§32.2 Evidence Check). The fix: build category awareness first; the comparison pages pay off once there are buyers searching for named options.

Exercise 32.21 †

(Guided — results vary by company.) The deliverable is a three-line funnel map for one real B2B company, e.g. for a project-management SaaS: ToFu — a page ranking for "how to run a project kickoff meeting" (informational); MoFu — a "project management software buyer's guide" or "Gantt vs Kanban" page (commercial); BoFu — a "[Product] vs [Competitor]" or "[Competitor] alternatives" page, plus a pricing page (commercial/transactional). If any stage has no page, that gap is the finding — most commonly the company is strong at ToFu (lots of blog content) and thin at BoFu (no honest comparison pages), which is exactly the imbalance §32.1 and §32.7 warn about. One sentence per stage on whether the page matches the intent the SERP shows for that query.

Exercise 32.23

(Guided — results vary.) The deliverable is a short reconnaissance note: for a chosen SaaS, whether [product] integrations returns a real hub and whether two [product] + [tool] searches return the vendor's own substantive page, a third-party directory, a forum, or nothing. A common finding: the vendor has a bare integrations directory but no substantive page per integration, so a directory site or a community thread is answering "[product] + [popular tool]" for it — a qualified, high-intent query handed to someone else. Name one such gap (e.g., "no dedicated, useful page for the QuickBooks integration despite clear search demand"). The caution to record: fill gaps with substantive pages (§32.4's five elements), never mass-generated thin templates.

Exercise 32.25 †

The gap between last-touch (6 of 40) and first-touch (21 of 40) shows organic search's real role is far larger than last-click suggests: organic started far more deals than it "closed," so judging SEO on last-click alone would badly understate it and could get the program cut. The number you would not report as precise truth is either single attributed figure — neither 6 nor 21 is "the truth"; first-touch over-credits the opener and last-touch over-credits the closer, and the gap between them is the size of the uncertainty, not a fact to bank. To a skeptical CFO: present organic's contribution as a range with the method stated, lead with multi-touch as the primary view, and corroborate with the self-reported signal (24% of buyers naming search/Google in "how did you hear about us?") — which independently confirms organic's large role and is often truer for touches that tracking (consent gaps, cross-device) misses. Honesty about the uncertainty is more credible than a confident single number.

Exercise 32.27 †

A model skeleton (yours may vary in wording) for an honest "FleetOps Alternatives" page for Dispatchr: - (a) The promise (one sentence): "If you're evaluating alternatives to FleetOps for field-service management, here's an honest look at where each tool fits — including where FleetOps is the better choice." - (b) A genuine concession: "FleetOps is the stronger option if you need [specific capability FleetOps genuinely leads on — e.g., a mature enterprise API, or a feature Dispatchr lacks]. If that's your priority, FleetOps is likely the better fit." (A real row where the competitor wins.) - (c) Where Dispatchr wins (specific segment): "Dispatchr fits best for growing home- and commercial-services companies with 10–200 technicians that want faster setup and [a specific, true differentiator] — the segment we're built for." - (d) Why trust this page: a clear statement that the comparison is maintained fairly, cites verifiable facts (public feature lists, real pricing tiers), links to independent reviews (G2/Capterra), and openly names who publishes it — the opposite of a rigged, "we win every row" table. Honesty is the mechanism that makes the page convert (§32.2).

Exercise 32.29

(Answers vary by product.) A model set for a field-service SaaS: ToFu (informational): "how to reduce technician drive time." MoFu (commercial/category): "field service management software: buyer's guide." BoFu (commercial-intent, ×3): "[Product] vs [Competitor]" (head-to-head), "[Competitor] alternatives" (a buyer leaving a named tool), and "field service software pricing." The lowest-volume, highest-value are the BoFu terms — especially the "vs" and "alternatives" queries, which may see only dozens of searches a month but catch late-stage buyers actively choosing, converting at rates no ToFu term matches. The point of the exercise is to feel the inversion: the biggest-volume query on the list is the least valuable per visit, and the smallest-volume ones are where the pipeline is.

Exercise 32.30 †

Classification and the pipeline-first pick: - how to reduce technician drive time (1,300/mo) → ToFu, informational. - field service management software (900/mo) → MoFu, commercial (category consideration). - FleetOps alternatives (60/mo) → BoFu, commercial (a buyer actively leaving a named competitor). - what is a work order (2,400/mo) → ToFu, informational (definitional; highest volume, lowest intent). - field service software pricing (110/mo) → BoFu, commercial/transactional.

Build first, for pipeline: FleetOps alternatives (or, close behind, the pricing page). Despite the smallest volume on the list, it captures the highest-intent buyer — someone already shopping and trying to leave a named competitor — and converts at a rate the 2,400-search "what is a work order" page never will. In pipeline terms, one page for 60 late-stage buyers can outproduce a page for 2,400 curious readers. Justify the pick by value per visit, not volume — the core B2B reframe of §32.1 and §32.7. (Build it honestly, per §32.2.)

Exercise 32.31

The myth is that topical authority is a function of article volume — that "360 AI-generated posts in six months" will "dominate your niche." Two things are wrong. First, there is no public "topical authority score" that rewards raw article count; Google says it rewards helpful, reliable content from sources that demonstrate real knowledge (§32.3 Evidence Check), which is about depth and expertise, not quantity. Second, mass-producing shallow AI content is exactly the "content at scale with little added value" that Google's Helpful Content systems (Ch 6) are built to catch — it can lower the site's quality signal, the opposite of the promised outcome (Case Study 2). A genuinely authority-building program: map the niche you actually sell into, publish a smaller number of genuinely definitive, expert-informed, interlinked articles at real depth (pillar + clusters, Ch 8), earn citations to them (§32.6), and accept that authority accrues over quarters, not weeks — which is exactly why it becomes a moat.

Exercise 32.33 †

A mini-funnel for Rivertown's commercial HVAC service line (contracts for offices, retail, and property managers): - ToFu (informational): "commercial HVAC maintenance checklist" or "how often should a commercial HVAC system be serviced" — a facilities/property manager learning, not yet shopping. - MoFu (commercial): "how to choose a commercial HVAC service provider" or "what's included in a commercial HVAC maintenance contract" — comparing approaches and providers. - BoFu (commercial/transactional): "commercial HVAC service contract [Rivertown metro]" or "commercial HVAC maintenance [city]" — ready to choose a local provider.

How to measure: success for the commercial line is signed maintenance contracts and their annual value (a pipeline metric), tracked from inquiries on the commercial pages — not blog pageviews. This differs from Rivertown's residential SEO, where the conversion is a fast, high-volume service-call booking and traffic tracks revenue reasonably well; the commercial line is a longer cycle, higher value, lower volume B2B purchase where traffic is a misleading scoreboard and pipeline is the true one (§32.7). The honest scope: this is a brief — a targeted addition for a specific high-value buyer — while Rivertown's real growth engine stays local SEO (Ch 25) and the service×city pages (designed in Ch 33).

Exercise 33.1 †

Programmatic SEO is the practice of creating many pages at scale from a single reusable template fed by a structured dataset — one page generated per record, each targeting a distinct, real search query. The formula: template (a fixed page skeleton with blanks — layout, headings, schema, internal-link modules) + data (rows in a database or spreadsheet) = pages at scale. It is legitimate when each generated page answers a real query with real, differentiated data (a real hotel's amenities, a real neighborhood's listings); it becomes spam when the "data" is nothing but a name swapped into otherwise-identical prose. The mechanism is neutral; the value of the result is what matters.

Exercise 33.3

The two forces Google names are the crawl capacity limit — how much crawling the site can tolerate, driven by server response speed and error rate (a fast, healthy server raises it; a slow or erroring one lowers it, because Google throttles itself to server health) — and crawl demand — how much Google wants to crawl the site, driven by its pages' popularity/importance, their freshness/rate of change, and the site's perceived quality. Effective crawl budget is roughly the two meeting in the middle: Google crawls as much as your server allows and as much as it judges worthwhile, whichever is less.

Exercise 33.5 †

Legitimate programmatic SEO, as described. Run it against the quality bar: each page carries three genuinely local paragraphs, real reviews from that city, and the real franchisee's name, address, and license — content a find-and-replace could not produce, useful to a searcher in that specific city, and differentiated per location. The page count (4,000) is not the issue, and neither is the template — templating is invisible to Google, which judges the finished page. This would be doorway spam only if the pages were near-identical spun text with the city name swapped. Two honest caveats: verify the "three local paragraphs" are genuinely differentiated (not lightly reworded boilerplate), and apply Rule 0 — if some of the 4,000 cells have no real demand or no real local presence, those specific pages should not be built.

Exercise 33.7 †

A template governs every page built from it, so a single change ships to all of them at once — that is the leverage and the risk in one property. Leverage example: changing the <title> template fixes 2,300 near-duplicate category-page titles in one deploy, a scale of improvement you could never match editing pages by hand. Risk example: a template change that ships a broken canonical, an accidental noindex, or malformed schema breaks all 2,300 pages at once — the Chapter 1 stray-noindex catastrophe scaled from one page to a whole section of the site. The same multiplier applies to quality and to junk with perfect indifference, which is why template changes must be sample-tested and monitored by page-type before and after rollout.

Exercise 33.9 †

The failing stage is discovery (recall Chapter 1's pipeline). The page is an orphan — no other page links to it — so even though it is indexed, it receives no internal link equity and Google has no internal path to keep re-finding and re-valuing it; quality alone cannot enter it into the ranking contest. The fix is structural, not editorial: wire it into the internal-link system — link it up to its service hub ("water heater repair") and its city hub (the Westbrook location page) and across to relevant siblings, per the double hub-and-spoke of §33.7 and Chapter 15. (If impressions remain near zero after it's well-linked and re-crawled, then check that "water heater repair Westbrook" has any real search demand at all — but the orphan status is the clear, first structural failure.)

Exercise 33.11 †

(Guided — the specific numbers are yours.) Deliverable: the share of 200 responses versus 3xx/4xx/5xx, plus the crawl trend. Interpretation guide: mostly 200s with a steady or gently rising trend means Google is crawling healthy pages without much waste — good. A high share of 404s and 301s means crawl is being spent on broken links and redirects — a fix opportunity (find and repair the sources). A sharp drop in total crawl can signal a crawl problem (server errors, an accidental block, or a quality signal falling); a sharp spike can signal a crawl trap (a parameter explosion). Tie the read to outcomes: are new/updated pages getting crawled promptly, or is the waste starving them?

Exercise 33.13 †

(Guided — varies by business.) Deliverable: the service×area matrix for a real business, with five demand-backed cells marked. Justify the picks with free tools: does "{service} {city}" autocomplete in Google Suggest (a signal real people search it)? Does Search Console already show impressions for those combinations? The five should be high-demand services in cities where the business has a genuine presence. The real lesson is Rule 0 — the winning cells are the intersection of real demand and a real local story, not "one cell per combination." If you cannot find demand or a local angle for a cell, it should not become a page.

Exercise 33.15 †

A model rewrite (local facts illustrative, and labeled so): "Cedar Hills is mostly 1950s and '60s housing, and the original gas furnaces in many of those homes are now well past their service life — which is why 'won't ignite' and short-cycling calls from the neighborhood spike with the first hard freeze every year. Our Cedar Hills crew works out of the Northgate branch, both lead technicians hold state HVAC licenses, and they stock parts for the older furnace models common on these blocks. Last winter they ran more than two hundred Cedar Hills furnace calls, most handled same day." Notice the rewrite reports real specifics — housing stock, the branch, the crew, seasonality — instead of repeating "furnace repair in Cedar Hills." That reporting of true, differentiated detail is exactly what a find-and-replace cannot produce, and it is the line between a location page and a doorway.

Exercise 33.16 †

The problem, in one sentence: more than three-quarters of Googlebot's finite crawl on this site is spent on parameter URLs, redirects, 404s, and noindexed pages, so the valuable indexable pages get a minority of the attention and are discovered and refreshed slowly. The two highest-priority fixes: (1) stop the parameter-URL crawl — canonicalize sort/view variants to the base page, noindex the thin filter pages, and only after they de-index add a targeted robots.txt block (Chapters 14 and 31); (2) flatten the redirect chains to single hops and fix the sources of the 404s so Googlebot stops wasting fetches. Then strengthen internal links to the deep money pages so crawl demand follows them, and re-pull the logs in a month to watch the ~22% climb.

Exercise 33.17

The single underlying cause is a server that is overloaded or degraded. Mechanism: Google's crawl capacity limit responds to server health — as average response time tripled, Google detected strain and throttled its own crawling to avoid harming the site, so total crawl requests fell ~70%. The two movements are one story: the slow responses caused the reduced crawl. The remedy is server-side — capacity, speed, reliability, a CDN — not an SEO tag; this is the capacity-limit lever of §33.5 running in reverse. (Worth ruling out a coinciding outage or a mistaken block, but the response-time signal points squarely at capacity.)

Exercise 33.18 †

False. Programmatic SEO — generating pages from a template and a dataset — is a legitimate, widely-used technique; Google evaluates the finished page's value, not its method of production, so there is no penalty for templating (any more than for using a CMS or AI assistance). What actually violates the guidelines are doorway pages and scaled content abuse: thin, near-duplicate, valueless pages produced — by any method — mainly to catch search traffic. The technique is white-hat; what crosses the line is the temptation it makes cheap, spinning empty pages at scale. State it precisely and you inoculate a client against both the fear ("we can't use templates") and the recklessness ("templates mean we can publish anything").

Exercise 33.19

It's wrong for the vast majority of sites: if a site has well under the large-site threshold (Google frames crawl-budget management as mainly for sites with on the order of a million-plus URLs, or large sites with rapidly changing content) and the server isn't erroring, Google already crawls everything it needs, and "crawl budget optimization" solves a non-problem. It's right for genuinely large sites — big e-commerce catalogs with heavy faceted navigation, large news archives, big programmatic properties — and medium-large, fast-changing sites. Evidence to decide: Google's own large-site guidance, plus your Search Console Crawl stats and your indexed-vs-real-page counts. If crawl was never the bottleneck (Rivertown's 75 pages, for instance), the effort is wasted.

Exercise 33.21 †

The risk: 300 spun "{service} {city}" pages are 300 doorway pages, plus scaled content abuse and keyword stuffing — a named spam-policy violation. The likely outcome: at best the pages simply don't rank (they carry no value to rank); at worst they trigger an algorithmic demotion or a manual action that drags down the whole site's quality signal, so even the pages that were good lose ground — and recovery is slow, requiring cleanup plus re-assessment (Chapters 6 and 26). It is downside with essentially no upside. The honest alternative: build only the cells with real demand and a real local story (Rule 0), each with a genuine local layer — start with the top services in the strongest cities and expand as they prove out. Frame it in the client's terms: a handful of real pages that actually rank and don't endanger the site beats 300 that rank for nothing and risk everything. Put the risk in writing; if the client still insists on the spam, that is an engagement that will cost you your reputation and possibly their site — be willing to walk.

Exercise 33.23 †

A ticket that would ship: - WHAT: Add LocalBusiness + Service (and FAQPage where a real FAQ exists) JSON-LD to the location-page template, populated from each page's existing structured fields (branch NAP, service, city, hours). - WHY: The location pages currently emit no structured data, so they are ineligible for the richer local/service search listings that lift click-through — listings competitors already show. (Illustrative impact: eligibility for local rich results on high-intent "{service} {city}" queries.) - SCOPE: Template-level change; renders on all location pages from data that already exists. No content rewrite required. - ACCEPT: Passes the Rich Results Test on 10 sample URLs across cities and services; the marked-up NAP/hours match the visible page; no new schema errors in Search Console after deploy. - PRIORITY: High impact × low effort (one template, existing data) — see the impact/effort matrix (Chapter 38). The point is that the stalled version ("add schema to the location pages") gives engineering nothing to estimate, prioritize, or verify; the rewrite gives them the change, the business case, the boundary, the definition of done, and the priority.

Exercise 33.25 †

Rule-based modules the template inserts by each page's position in the data, for a ~40-cell service×area matrix: 1. Up-to-service-hub link — each leaf ("furnace repair in Westbrook") links up to its service hub ("furnace repair"). 2. Up-to-city-hub link — each leaf links up to its city/area hub (the Westbrook location page from Chapter 25). 3. Service-across-cities module — the service hub links down to that service in every area, and each leaf links across to the same service in nearby areas. 4. Other-services-in-this-city module — each leaf links to a limited, relevant set of other services in the same city (not all of them). 5. Breadcrumb — Home › Services › {Service} › {City}, giving hierarchical up-links and breadcrumb schema. Result: every leaf has multiple inbound internal links (no orphans), sits about two clicks from the homepage, and receives authority from both the service and the city dimension. Keep the sibling modules limited and relevant to avoid link mazes and over-linking, and vary anchor text naturally rather than repeating one exact-match phrase across thousands of links.

Exercise 33.27 †

Because anyone can send a request carrying Googlebot's user-agent string, and scrapers and spammers routinely do — so an unverified "Googlebot" line in your logs may be an impostor, and analyzing impostor traffic would corrupt your entire crawl picture. Verification uses Google's published method: perform a reverse DNS lookup on the requesting IP address; it should resolve to a googlebot.com or google.com hostname; then perform a forward DNS lookup on that hostname and confirm it returns the original IP. (Google also publishes its crawler IP ranges, which you can match against.) Filter your logs to verified Googlebot before drawing any conclusion.

Exercise 33.29 †

Apply Rule 0 — do not auto-build all 75. Score each cell by (a) real search demand for "{service} {city}" and (b) a real local story and presence. Phase 1 (~25 cells): the five highest-demand, universally-needed services — AC repair, furnace repair, water-heater replacement, drain cleaning, and panel upgrade — across all five cities (Rivertown, Cedar Hills, Northgate, Westbrook, Millhaven), which is $5 \times 5 = 25$ cells. Criteria: demand (these five carry the clearest "{service} {city}" search volume in every city) and capability (Rivertown genuinely performs all five in all five cities, with real crews and real proof). Defer or merge the lower-demand or thin-presence cells — for example, EV-charger installation in a city with little new construction — until they earn their own page. Twenty-five strong pages beat seventy-five where a third are thin, because the thin ones drag the site-wide quality signal down and dilute the crawl.

Exercise 33.30 †

A pre-publish anti-doorway checklist (each item a gate; fail one and the page does not ship), with what each protects against: 1. "Does this page contain at least three-to-five true, specific facts about this service in this city that a find-and-replace could not produce?" — protects against spun / near-duplicate content, the core doorway signal. 2. "Would this page be useful if it were the only page on the site?" — protects against pages that only make sense as one of many clones. 3. "Is there real local proof — a real branch/team serving this city, real local reviews or job photos?" — protects against fabricated or absent local presence. 4. "Is there real search demand for this service in this city?" — protects against building pages nobody searches for (crawl waste and quality dilution). 5. "Does the title and <h1> match the query without keyword-stuffing?" — protects against the stuffed doorway heading and intent mismatch. Each question corresponds to a specific way doorway spam gets built; passing all five is, operationally, the difference between a legitimate location page and a doorway.

Exercise 34.1

Google News is Google's dedicated news product (the News tab, news.google.com, the News app) — a curated, personalized stream of journalism. Google Discover is a personalized, query-less feed on mobile that surfaces content by inferred interest, before any search. Evergreen content is content whose value and relevance persist over time (with updating), producing compounding traffic. The single most important difference in optimization: for Search you optimize against a query (intent, keywords, position); for Discover there is no query — you make yourself eligible (indexed, policy-compliant, well-illustrated, trustworthy) and hope Google matches you to a reader's interest.

Exercise 34.2 †

You do not submit or pay to get into Google News; inclusion is automatic for sites that publish genuine news content and follow Google's news policies. The Publisher Center manages how your publication is presented — its name, logo, and sections — not whether you appear. A "get into Google News" service is selling you access to a door that is already open for free (and which no one can actually guarantee), so the money is better spent on real reporting and on eligibility basics (originality, clear dates, crawlability, a news sitemap, author/publisher trust).

Exercise 34.3

A news sitemap is a specialized, additional sitemap that lists only articles from roughly the last 48 hours, each with a <news:publication> block (publication name + publish date). Articles roll off after ~2 days. Its purpose is speed: it flags very fresh URLs so Google prioritizes crawling them inside the short window a breaking story is worth ranking. A regular XML sitemap (Ch 14) is a general discovery aid for the whole site and is not time-limited; the news sitemap sits alongside it and only matters if you publish genuinely time-sensitive news.

Exercise 34.4 †

Flexible sampling is Google's approach (2017, replacing "First Click Free") that lets paywalled content stay indexable without cloaking. Its two flavors are metering (each reader gets N free articles per period, then the wall goes up) and lead-in (everyone gets a free excerpt, then the wall). It is not cloaking because you declare the paywall to Google with paywall structured data (isAccessibleForFree: false marking the gated section) — you are telling Google exactly what is free and what is gated, not secretly serving Googlebot different content than humans.

Exercise 34.5

NewsArticle schema is the Schema.org structured-data type for a news article (a subtype of Article) that states the headline, publish/modified dates, author, and publisher in a machine-readable form. The two date fields the chapter singles out are datePublished and dateModified — they must be truthful (faking freshness by restamping old dates is a trust violation). NewsArticle schema is not a direct ranking factor; it aids Google's understanding and eligibility for news presentation, nothing more.

Exercise 34.6 †

Content syndication is republishing the same content on other domains by agreement (wire services, partner networks, larger outlets). Canonical attribution is using rel="canonical" across domains (and stronger measures like the republisher's noindex) to tell Google which URL is the original that deserves ranking credit. The honest completion: "A cross-domain rel=canonical is a hint, not a directive (guarantee)." Across domains Google may override it — especially when the republisher has higher authority.

Exercise 34.7

Concrete rule: treat Discover as upside, never as a baseline. Because Discover has no query to target and no guaranteed entry, its traffic is bursty and unpredictable — huge one day, gone the next. So forecast and budget the business on Search plus owned channels (which you can influence), count zero reliable Discover revenue in the plan, and treat every Discover spike as a windfall to bank (convert readers to email, add internal links to evergreen), not as recurring income to staff against.

Exercise 34.8 †

For the editor: a pure-breaking strategy is fragile because breaking news has a half-life measured in hours to days — each post spikes and dies, so the moment you stop publishing, the traffic stops. You are on a treadmill: last month's 1,200 posts earn almost nothing today, and the archive becomes a mountain of dead pages that can hurt the site's quality signal at scale. The compounding alternative is evergreen content — definitive explainers that stay valuable for years (with periodic updating), building slowly and paying out continuously. The healthiest newsrooms run both: breaking coverage builds audience and authority; that interest is converted into evergreen assets that keep earning while you sleep. (Theme 6: the long game.)

Exercise 34.9

Google's Helpful Content and core systems assess quality partly at the site level, not just page by page. A large archive of decayed, thin, once-breaking articles that now earn nothing collectively signals "this site produces low-value content at scale," and that verdict can drag down how Google judges the whole domain — including the good, current pieces. This is the content-audit anchor: the counter-intuitive cure is not to publish more but to prune, merge, and update the archive, raising the site's overall quality signal so the pages that can still work get room to rank. Publishing less can grow traffic more.

Exercise 34.11 †

The violation is cloaking — showing Googlebot different content (the full article) than human readers (a paywall), with no declaration, is a spam-policy violation regardless of intent. The sanctioned way to achieve the same goal is flexible sampling with paywall structured data: serve Google the full content and mark the page with isAccessibleForFree: false, identifying the gated section (via a CreativeWork/hasPart block). That declaration tells Google the content is legitimately gated, so it can index and rank the full article while the human paywall is not treated as cloaking — you declared the gate instead of hiding it.

Exercise 34.13

"AMP lost its Top Stories privilege" is true: the June 2021 Page Experience update ended AMP's role as the requirement for the Top Stories carousel, opening it to any fast, quality page. "Web Stories are a dead technology" is false: Web Stories are an actively supported content format (the open-web successor to AMP Stories) that still appears in Discover and Search. The distinction matters because a publisher deciding where to invest should (a) no longer build or keep AMP just for Top Stories, and (b) still consider Web Stories where a visual, mobile format genuinely serves the content — but never as a ranking cheat.

Exercise 34.15 †

The problem is at the rendering/indexing boundary: Google never saw the gated body, only the free lead-in excerpt, so there is effectively nothing beyond the excerpt for indexing and ranking to work with — the page competes as if it were only the intro. The fix: implement flexible sampling correctly so Googlebot receives the full article HTML, with the paywalled portion declared via paywall structured data (isAccessibleForFree: false + the gated section marked). Then Google can index and rank the complete content while humans still hit the paywall — indexable and compliant, instead of thin-by-accident.

Exercise 34.17 †

Two non-technical dimensions to investigate first: (1) Content quality / helpfulness and E-E-A-T (Chapters 5, 13, 35) — after a core update, evergreen health pages often slip because the site-level quality or trust bar rose; check author credentials, the review process, sourcing, and whether the content is genuinely more helpful and original than competitors'. (2) Content decay / freshness (Chapter 12) — evergreen is only evergreen if maintained; stale statistics, outdated guidance, or newer, more complete competitors can erode rankings. The instinct to hunt for a technical bug is usually the wrong first move here; core-update slippage is a quality/trust judgment, not a broken tag.

Exercise 34.19

The risk is a site-level quality demotion. Thousands of AI-generated posts a day is exactly the "scaled content abuse" that Google's Helpful Content and spam systems target (Chapters 6, 13) — and quality is assessed partly across the whole site, so even if some individual posts pass a quick read, the mass of unoriginal, low-value pages can drag down how Google judges the entire domain, harming the site's good content too. The threat isn't just that those posts won't rank; it's that they can poison the well for everything else. The lesson: AI as an unedited scale machine is a site-wide liability, not a per-page gamble.

Exercise 34.20 †

(Guided — answers vary by site.) The deliverable is an observation, not a fix. If a Discover report exists in Search Console, you've had Discover traffic in the last ~16 months — record whether the line is a steady stream or a few giant spikes, and note the single top page (usually one article carries a disproportionate share). Example write-up: "Discover report present; ~80% of clicks came from three spike days tied to two articles — classic bursty, article-driven Discover, so I'll treat it as upside not baseline." If there's no Discover report, that simply means you've never been surfaced there — the norm for most sites, and not a problem to fix.

Exercise 34.21

(Guided.) Look for max-image-preview in the page source / robots meta. If it reads max-image-preview:large, you've enabled large image previews, which Google says helps Discover presentation — good. If it says standard or is missing, you may be capping your own image previews and undercutting Discover eligibility; the change is to set max-image-preview:large (site-wide via the robots meta or X-Robots-Tag) and ensure articles use high-quality images ~1,200px wide or more. This is one of the few Discover levers actually in your hands — but enabling it removes a blocker; it does not guarantee Discover traffic.

Exercise 34.23

(Guided.) For each key author, confirm there is a real author page (bio, credentials, areas of coverage) and that the byline links to it. Common gaps: bylines that say "Admin"/"Staff," author pages with no credentials, or bylines not linked at all. A concrete one-week improvement: create or flesh out author pages with genuine credentials and link every byline to them; for expert/YMYL topics, add a named, dated reviewer line ("Medically reviewed by …"). The point is real, corroborable author identity — the kind Google can triangulate across the web (Chapters 5, 35) — not a cosmetic byline.

Exercise 34.24 †

(Guided.) If you publish time-sensitive news, check for a sitemap containing <news:publication> blocks (that's a news sitemap) and confirm your articles carry correct, honest datePublished/dateModified values. Model finding: "We publish daily news but have no news sitemap and inconsistent timestamps — fresh stories are slow to appear in Top Stories; action: generate a news sitemap and fix date markup." If you publish no news, a news sitemap would be the wrong thing to build — it's only for genuinely time-sensitive articles from the last ~48 hours; adding one to an evergreen site does nothing useful and misrepresents non-news content as news.

Exercise 34.25 †

The mix reveals acute single-source fragility: Discover is nearly as large as Search but ~70% of it comes from four spike days, and one article alone drove 620,000 of those clicks — so a huge share of the business rests on unrepeatable, uncontrollable feed events, while email/direct (the owned, resilient channel) is a rounding error at 40,000. The number that should worry you most is not the big Discover figure but the tiny email/direct 40,000: it means almost no owned audience to fall back on. The single biggest risk is that a core update or Discover shift halves traffic overnight with nothing to fix. Two first moves: (1) aggressively convert Discover spikes into owned audience (newsletter signups, returning-reader habits, internal links to evergreen); (2) invest in compounding evergreen + real E-E-A-T so Search becomes a controllable, growing base rather than a distant second.

Exercise 34.27

Two problems. (1) "name": "Staff" — an anonymous byline provides no author E-E-A-T; Google cannot connect the content to a real, corroborable expert, which is especially damaging for a health/YMYL topic. Fix: a real named author linked to a substantive author page (and, for health, a credentialed reviewer). (2) The date mismatch plus the clickbait headline — datePublished 2021 with dateModified 2026 on a piece titled "10 Foods That Melt Fat Overnight" suggests either a genuine update (fine, if the content really changed) or freshness-faking (a trust violation if the date was bumped without substantive change); and the sensational, unsupported health claim in the headline is exactly the kind of low-quality YMYL content the quality systems penalize. Fix: truthful dates that reflect real updates, and an accurate, non-sensational headline backed by credible sourcing.

Exercise 34.28 †

(a) Brand reach, ranking doesn't matter: syndicate freely and use a prominent link back to the original — you're buying exposure and referral traffic, so don't spend effort protecting a ranking you don't care about. (b) Ranking is strategically critical: get the partner to noindex their copy (the strongest realistic protection), publish and get indexed first, and ideally syndicate a differentiated/delayed version rather than a verbatim one; treat a cross-domain canonical as a weaker fallback since Google may override it. (c) Partner refuses to noindex or canonical: minimize competition by syndicating a variation (partial, later, or differentiated) rather than the full verbatim piece, and accept that if you must syndicate verbatim to a higher-authority domain, their copy may outrank yours — so decide whether the reach is worth ceding the ranking before you sign.

Exercise 34.29

Two false claims. (1) "Pay us \$2,000 and we'll get you into Google News" — inclusion is automatic and free for sites publishing genuine news that follow the policies; no one can sell or guarantee it (the Publisher Center only manages presentation). (2) "Add big images and you're guaranteed Discover traffic" — large images help eligibility/presentation, but Google states plainly there is no guaranteed way into Discover; eligibility is not entry, and there's no keyword or lever that forces it. Truth: do the image/preview work because it removes a known blocker, but treat any guarantee of News or Discover placement as snake oil.

Exercise 34.30 †

Both tactics fail the book's ethics and evidence standards. Restamping 500 old articles with today's date is freshness-faking — misrepresenting datePublished/dateModified is a trust violation Google discourages, and it doesn't make stale content genuinely fresh. The honest alternative: actually update the pieces (historical optimization, Ch 12) and let the modified date reflect the real change. Buying "expert reviewer" bylines for health content is fabricating E-E-A-T — the exact opposite of the lesson that author authority can't be faked at scale, and dangerous for YMYL (Ch 35). The honest alternative: engage real credentialed reviewers, name and date their review, and build genuine author entities. In both cases the fake is not just unethical; it's ineffective, because Google corroborates dates and authors against the wider record.

Exercise 34.31

Two-sided answer. A paywall costs SEO/reach: gated content risks being invisible to Google (and to readers who won't subscribe), and an aggressive wall can dampen the engagement and satisfaction signals Google's systems ultimately chase. Flexible sampling resolves the technical half: with metering or lead-in plus paywall structured data, the full content is indexable and rankable without cloaking — so "drop the paywall so Google can rank everything" is unnecessary on technical grounds. But how much to sample — how many free articles, how large an excerpt, how hard the wall — is a business judgment balancing reach against subscription revenue, not an SEO decision. The technical setup is settled; the gating strategy is a revenue-model call the SEO can inform but not make.

Exercise 34.32 †

Talk them down: Rivertown is a home-services company, not a media outlet — chasing Google News, Web Stories at scale, Discover as a strategy, or paywalls would waste effort and teach the wrong reflexes. Two things to borrow: (1) Evergreen depth — Rivertown's wins are timeless how-tos ("why is my furnace blowing cold air") that compound for years, so invest there rather than trying to be timely; (2) Compelling, honest titles + a strong real image on those posts (the publisher's headline/image craft, minus the clickbait Discover punishes) — and, relatedly, real technician bylines for author trust. Two things to ignore: (1) Google News / news sitemaps — Rivertown publishes no news; (2) Discover as a plan — nice if a how-to ever surfaces, never something to rely on (no keyword, no guaranteed entry). Bonus real value: the diversification lesson at local scale — Rivertown's phone, reviews, and repeat customers are its insurance.

Exercise 34.33

(Guided — answers vary by site.) Deliverable: a three-bucket sort (breaking / analysis / evergreen) of a content sample, one named best-evergreen asset, one named decayed page needing the Ch 12 keep/update/merge/delete treatment, and — most important — a written answer to "if Google halved my organic traffic next month, what channel keeps the business alive?" Example: "Best evergreen: the 'furnace won't start' guide (steady leads for 3 years). Decayed: a 2022 'spring HVAC deals' post, now dead — merge or remove. If Google halved traffic: our email list and repeat-customer base would carry us, but the list is thin — so building it is the priority project." If the honest answer is "nothing," the first sentence of the fix-it project (an email capture, a brand/reviews push, a community) is the assignment — and it's a business project, not an SEO tactic.

Chapter 35 — Worked Solutions (daggered † and odd-numbered exercises)

Solutions for the answers appendix. Covers all odd-numbered items plus the daggered ones (35.2, 35.8, 35.14, 35.18, 35.20, 35.22, 35.26, 35.30, 35.32). Hands-on/audit items give a model of a strong answer. Every solution holds the chapter's guardrail: demonstrate trust, never fake it; no medical/financial/legal advice.

Exercise 35.1

YMYL ("Your Money or Your Life") is Google's classification for topics where wrong information could significantly harm a person's health, financial stability, safety, or the well-being of society. The test: if this page is wrong — or written maliciously — who gets hurt, and how badly? The stakes decide it, not the subject's difficulty.

Exercise 35.2 †

The four broad categories: health & safety (e.g., medication information — harms: physical injury, delayed care, death); financial security (e.g., retirement or tax information — harms: lost money, debt, fraud); society (e.g., civic/legal/voting information — harms: legal jeopardy, disenfranchisement); other high-stakes (e.g., housing, employment, nutrition in certain framings — harms: life-altering decisions on bad information). Expanded example: a wrong page on a drug interaction can lead a reader to combine medications dangerously — direct physical harm.

Exercise 35.3

Credentialed authors (partly machine-readable via author markup) — a named, qualified, verifiable person behind the content. Expert review (partly machine-readable via reviewer markup/dates) — a qualified professional verifies accuracy and is named with a date. Source citations (mostly not machine-readable as a trust judgment) — claims tied to primary reputable sources. Transparency/editorial standards (mostly not) — real About/Contact, funding disclosure, a real editorial process. The first two are partly declarable to machines; the reputation underneath them, and the last two, are judged largely by what independent sources say.

Exercise 35.5

Trust is the center of E-E-A-T because Experience, Expertise, and Authoritativeness are all inputs to a single question — can this be trusted? On a hobby page, a lapse in trust costs little. On a YMYL page, the whole reason for the higher bar is that untrustworthy content can harm the reader, so a trust failure (inaccuracy, hidden conflict, staleness) is disqualifying in a way it is not for a cookie recipe. Same framework, far higher consequences.

Exercise 35.7

(a) "best sci-fi novels 2026" — not YMYL (a wrong answer wastes a little time). (b) "how to lower a fever in a toddler" — YMYL (health of a vulnerable person; wrong info can harm). (c) "is a Roth conversion right for me" — YMYL (financial security; consequential money decision). (d) "how to reset a tripped breaker safely" — YMYL/borderline-strong (physical safety; electrocution/fire risk if wrong). (e) "best pizza in Northgate" — not YMYL (taste, low stakes). The test each time: harm potential if wrong.

Exercise 35.8 †

On a hobby topic, coasting on thin content merely underperforms — a bad cookie recipe loses to a good one, and that is all. On YMYL, the entire purpose of the quality apparatus is to stop sending searchers to untrustworthy answers where a wrong answer harms them, so thin/anonymous/unreviewed content is not just weak — it is the specific thing the system is built to find and demote. "Medic" was a maturing quality system catching up to the published rater rubric on high-stakes topics; there was no missing signal to add and no trick to run, because the deficiency was the absence of real credibility. You cannot out-trick a bar that exists precisely to detect the trick.

Exercise 35.9

Not trustworthy. Every signal is present (author, reviewer line, citations) but the substance has failed: claims contradict current guidance and the content is unmaintained. Because Trust is the center of E-E-A-T and accuracy is the substance a citation only points at, the outdated, contradicted claims sink the page regardless of decoration — and the citations make it worse by lending false credibility to wrong information. The remedy is a real re-review, corrected claims, and an honest date, not more signals.

Exercise 35.11

Google has stated that linking out to authoritative sources is not a ranking booster — there is no bonus dispensed for the domains in your citations. Citations exist to (1) let a reader verify your claims and (2) demonstrate the diligence a credible YMYL page is expected to show. Treating them as a hack produces citation-stuffing — decorating inaccurate content with authoritative-looking links to launder it — which helps neither the reader nor the ranking, because accuracy, not the citation, is the substance.

Exercise 35.13

A dated, visible corrections policy shows the process is real and self-policing: the site checks its work, admits errors, and fixes them transparently. A publisher that never corrects anything is either implausibly perfect or not looking — both worse for trust. Correction demonstrates accountability, which is exactly what a reader on a high-stakes topic needs to see.

Exercise 35.14 †

The two-level stack: author entity (a named, credentialed person whose reputation independent sources corroborate) and organization entity (a real, disclosed publisher with a genuine editorial process and track record), both resting on the page's own accuracy/review/sourcing/transparency, together feeding Google's estimate of whether the page can be trusted. Weak-org example: a genuinely credentialed doctor publishing on a thin, anonymous, ad-choked domain — the organization drags the expert down. Weak-author example: a reputable-looking publisher shipping anonymous, unreviewed health content — the org's polish cannot cover the missing human accountability. YMYL wants both genuine and aligned.

Exercise 35.15

In priority order, before "the writing isn't good enough": (1) No credentialed author — anonymous authorship on a consequential health topic fails the reputation-research expectation. (2) No expert review / accountability layer — nothing and no one vouches for accuracy. (3) No sourcing — claims are unverifiable. (4) Weak organizational E-E-A-T — a year-old anonymous domain has no reputation for Google or a reader to check. The content may be genuinely accurate, but on YMYL the credibility is illegible, and that outranks the content-quality question until it is fixed.

Exercise 35.17

Model answer: the student lists their site's pages and applies the harm test to each, separating (a) fully YMYL pages (if the site is a health/finance/legal site) from (b) YMYL-adjacent pages on an otherwise non-YMYL site — e.g., a fitness studio's "is this exercise safe after injury?" post, a hardware store's "how to use a space heater safely" guide, a home-services blog's gas/electrical safety pieces. Strong answers note that most of the site is likely not YMYL and resist over-applying the higher bar to ordinary pages.

Exercise 35.18 †

Model answer: for the chosen consequential query, the student records for each top-five result the named author + verifiable credential and the organization + its open-web reputation, then writes an honest go/no-go. A strong response names the credibility gap concretely ("the winners are institutions and CFP-bylined publishers; we have neither a credentialed author nor institutional standing") and reaches a real decision — compete by hiring/partnering for genuine credibility, reframe to honest experience content, or don't target this query — rather than proposing formatting tweaks.

Exercise 35.19

Model answer: a mixed list of ten queries, each tagged YMYL / not / borderline with a one-line harm rationale, and a flag on those requiring genuinely credentialed authorship. Strong answers show the gray zone (e.g., a food's taste vs. its safety in pregnancy) and correctly reserve the "requires a credential" flag for pages that make consequential claims, not merely difficult ones.

Exercise 35.20 †

Model answer: for the chosen YMYL query, a catalog of the credibility markers in the top five (named credentials, dated review lines, quality and type of citations, organization type — institution vs. publisher vs. government), followed by an honest needs list dominated by people, process, and reputation (a real credentialed author; a genuine reviewer; institutional standing or recognition) rather than formatting. The tell of a weak answer is a list of on-page tweaks; the tell of a strong one is naming what you'd have to genuinely become or hire.

Exercise 35.21

Model rewrite (no invented facts): Written by [real staff writer, named] · Medically reviewed by [real, named, credentialed professional] on [today's date] · Sources: [links to primary/reputable references] · Last updated [date]. The point is that you must gather real facts first: identify the actual writer, engage a genuinely qualified reviewer who really reviews it, and assemble real sources. If those people and that process do not exist, the honest output is not a header — it is the §35.6 decision to hire them, reframe, or not publish. You may not fill the blanks with fiction.

Exercise 35.22 †

Honest steps, in order: (1) Assess capability — does the site have, or can it engage, a genuinely qualified author/reviewer for this condition? (2) If yes: commission a credentialed author (or have a qualified professional review a skilled writer's draft), add a real dated review line, cite primary sources, add currency and correction signals, and disclose any funding. (3) If no: choose an honest path — reframe to non-advisory content the site can credibly own (e.g., "what to expect at an appointment," clearly not diagnosis), or don't publish the symptoms page at all and, if useful, point readers to genuinely qualified resources. The decision not to publish is a legitimate, sometimes correct, professional output — not a failure.

Exercise 35.23

Honest rewrite: "[Name] is a [real credential, e.g., CERTIFIED FINANCIAL PLANNER] with [X] years advising [audience] on [topic]. They write here on [specific area]." Annotations of the original vs. honest version: "#1 most-trusted"/"read by millions" = unverifiable self-declared Authoritativeness (weak — you can't assert your own reputation); "secrets banks don't want you to know" = manipulative framing, not a trust signal. The honest version maps: credential → Expertise; years/volume → Experience; named person → Trust/verifiability; specific focus → topical relevance. Authoritativeness is earned from others, so it is (correctly) not asserted in the bio.

Exercise 35.25

Legible trust: a named staff writer. Missing/suspect, in order to verify: the "reviewer" has no link, no specialty, no date — treat as unverified and verify first (does "Dr. J. Smith" exist, in the relevant specialty, and did the review actually happen?); the two "citations" point only to the site's own pages — that is circular, not sourcing; the "Trusted by millions" badge is self-declared and worthless; the mid-article supplement ad hints at an undisclosed conflict on a YMYL page. First action: verify the reviewer is real, qualified, and actually reviewed it — because if not, the page is a §35.6 fabrication, not a fixable draft.

Exercise 35.26 †

Myths and false claims: (1) "YMYL penalty" — there is no YMYL penalty or flag to remove; YMYL raises a quality bar, it is not a switch. (2) "suppressing your site" — a core-update demotion is not a suppression to lift; it is a relative reassessment you answer by improving genuine quality. (3) "removes" — implies a mechanical fix; there is nothing to remove. (4) "guarantees page one within 90 days" — no one can guarantee rankings (Google decides; competitors vary), and a timeline guarantee on earned quality is a hallmark of snake oil. Honest correction: become genuinely more credible and make it legible; recovery from a core-update demotion is slow, reassessment-based, and never guaranteed.

Exercise 35.27

Myth: that a "medically reviewed by" line is a fast ranking boost. Correction: the line matters only if the review actually happened and the reviewer is a genuine, verifiable professional — it is a way to make a real accountability process legible, not a lever to pull. The ethical problem hiding in the SEO claim: the framing invites adding the line without the process (fabrication), which on YMYL is a deception of vulnerable readers and a potential harm — the exact counterfeit §35.6 forbids.

Exercise 35.29

The line is the difference between disclosed commerce and disguised advice. Selling supplements you disclose you profit from, with honest claims, is legitimate commerce. Presenting the same pages as neutral guidance while steering readers to the products you earn on — hiding the motive — is deceptive, and on a health topic it is YMYL harm. Honest reframe: clearly separate and disclose the commercial relationship ("we sell these; here's our stake"), keep any health claims accurate and within what qualified people will stand behind, and never let the sales goal override accuracy. If the business model requires disguising the motive, the model, not the copy, is the problem.

Exercise 35.30 †

Scenario: a general-interest content site with no medical staff and no budget to hire any wants to publish "how to treat [serious condition] at home" pages because the keywords have volume. Correct recommendation: do not publish this. Reasoning: the site has neither author nor organizational expertise; faking either is deception and potential harm; and there is no honest reframe that makes unqualified treatment advice acceptable (unlike a first-hand experience piece, treatment instructions are inherently advisory). What to tell an insistent client: the downside is not just a fragile ranking but real harm to readers and real liability, the content will not durably rank without genuine credibility anyway, and the professional move is to either invest in real expertise or pursue topics the site can honestly own.

Exercise 35.31

Model handling for "Is it safe to reset a tripped breaker myself?": named expert = Rivertown's licensed master electrician (reviewer/byline). Authorities cited = the National Electrical Code and manufacturer/panel guidance, plus general fire-safety guidance — as verifiable sources, not authority Rivertown claims. Bright line: explain that a single trip that resets normally is common, but repeated tripping, burning smells, scorching, or any uncertainty means stop and call a licensed electrician — and do not publish instructions for opening the panel or working on wiring. What Rivertown can honestly say from experience: what causes trips, what the warning signs mean, what to expect from a service visit, and when it is urgent. The page's job is to inform and route to a pro, not to coach dangerous DIY.

Exercise 35.32 †

Model one-paragraph policy: "Before publishing any page that touches safety (gas, carbon monoxide, electrical, water/scald, or anything where a reader could be physically hurt): (1) confirm a named, licensed Rivertown expert (Tony Delgado for gas/combustion; our licensed master electrician for electrical) has reviewed and is bylined on it, with a date; (2) lead with the safe action, and for any emergency (e.g., suspected gas leak) put 'leave and call 911 or the gas utility from outside' first; (3) cite real authorities (manufacturer instructions, the National Electrical Code, local codes, fire/utility guidance) as sources, never as authority we claim; (4) never publish step-by-step instructions for dangerous DIY — inform the reader and route them to a licensed professional; (5) if we cannot satisfy 1–4, do not publish the page." Strong versions keep every rule executable by a non-expert writer and make "don't publish" an explicit option.

Exercise 36.1

AI Overviews are AI-generated summaries Google places atop the results for some queries, with a few cited sources. SGE (Search Generative Experience) was Google's 2023 opt-in Search Labs experiment that put an AI answer across the top of results. Zero-click search is a search that ends without a click because the page answered it in place. Answer engine is any search-like system whose main output is a synthesized answer, not a link list. Relationship of the first two: SGE was the experiment; AI Overviews is the product it became when the feature graduated from Labs to a broad rollout (US, 2024) — which is why the terms are often used almost interchangeably.

Exercise 36.2 †

Retrieval (retrieval-augmented generation) is the step where an answer engine first fetches relevant pages from an index and then has a language model write an answer grounded in what it fetched, usually citing some of those pages. "AI Overviews are built instead of the ranked web" is wrong because the Overview is built on top of that web: it summarizes and links pages that were crawled, indexed, and ranked by the same machinery classic SEO targets (for Google's AI Overviews, literally the same index). The AI layer is a new front end on the familiar back end — so the crawlability, relevance, authority, and trust work of this book now also feeds AI visibility rather than being replaced by it.

Exercise 36.3

Generative engine optimization (GEO) is the practice of improving your content's odds of being retrieved, cited, and linked by AI answer engines (a.k.a. answer engine optimization). An LLM citation is your page being named/linked inside an AI answer. GEO is "mostly SEO with the citation as the new prize" because the mechanism runs through retrieval: answer engines cite what they retrieve, and what they retrieve is largely what ranks well, is clearly structured/quotable, is authoritative and widely referenced, and carries information gain — i.e., the exact qualities good SEO already builds. There is no separate secret method; the prize changed (a citation, not just a blue-link click), the work mostly didn't.

Exercise 36.5

The chain is: intent → format of the answer → whether an AI summary can satisfy it → commercial value. Simple informational intent ("what is a SEER rating") can be satisfied by a sentence, so it is highly AI-exposed — and the person asking it is usually not about to buy, so it has low commercial value. Transactional/local intent ("book a tune-up," "repair near me") requires an action or a real, accountable provider an answer can't be, so it is barely exposed — and it is where the customer with a wallet out actually is. Because exposure rises with summarizability and commercial value falls with it, the AI answer absorbs the low-value informational traffic and leaves the high-value transactional/local traffic largely intact: "eating the traffic worth the least."

Exercise 36.6 †

Most-exposed → least-exposed: 1. "what is a heat pump" — simple informational/definitional; a sentence answers it. Highest exposure. 2. "heat pump vs furnace cost" — commercial investigation; a summary helps, but a several-thousand-dollar decision drives serious readers to deeper comparison. Medium exposure. 3. "emergency plumber near me" — local + urgent; needs a real nearby provider (a map pack and a phone call), which no paragraph can be. Very low exposure. 4. "book ac tune-up" — transactional; the click is the action, which an answer can't complete. Very low exposure. 5. "rivertown home services" — navigational/branded; they want a specific site, so there is no generic answer to substitute. Lowest exposure. (3, 4, and 5 are all "very low"; the defensible ordering puts navigational last because a named-brand search has literally no substitute answer, then transactional, then local — but the key insight is the cliff between #1–2 and #3–5, not fine distinctions within the resilient group.)

Exercise 36.7

Corrected: "Being cited by an AI is valuable but not the same as getting the click — you can win the citation and still lose the visit if the searcher's need is met inside the answer." What a citation still buys: brand exposure (your name appears inside the answer, in front of the searcher), a possible click on the cited link, and evidence you are in the answer engine's trusted retrieval set. It is real value that compounds into brand — just not a guaranteed session, which is exactly why citation strategy must sit next to diversification rather than replace it.

Exercise 36.9 †

Optimizing for one predicted future means committing resources as if a specific outcome is certain — e.g., "AI will take all informational traffic, so we delete our blog and bet everything on paid social." If the prediction is wrong (or the timing is off), the commitment backfires. Building for robustness means making choices that pay off across many futures and hedge the rest — e.g., keep the blog but repurpose it to build brand and feed AI citations, and build an email list, and deepen reviews, and keep winning local/transactional queries. Concrete: betting the business on one AI-search forecast (fragile) vs. building owned channels that help whether AI Overviews grow, plateau, or retreat (robust). Uncertainty argues for the second: you can't predict the future, but you can be hard to kill in most versions of it.

Exercise 36.11

Most likely cause: an AI Overview (and/or other SERP features) absorbing the click on an informational query — the ranking-vs-traffic decoupling (§36.2). Stable impressions + stable #1 ranking + falling clicks is the signature. Two moves the chapter recommends: (1) be the cited source in the Overview (§36.4) so at least the brand exposure survives a no-click impression, and (2) stop depending on this page's click — deepen it to answer the follow-up a summary skips (win the click-worthy visit) and diversify traffic to owned channels (§36.5). It is not a ranking failure — the page won the contest it entered; the contest's prize (a click) got smaller.

Exercise 36.13

The 80%-informational site is far more exposed: its traffic base sits in the most AI-absorbed intent category (§36.3), so it faces the zero-click squeeze directly and should prioritize (a) repurposing informational content to build brand and earn AI citations, (b) deepening it past the summarizable fact for information gain, and above all (c) urgently building owned channels (email, brand, direct) — it has a single point of failure. The 80%-transactional site is relatively resilient (transactions can't be answered away) and should prioritize protecting and growing that converting traffic (local, product, booking) while treating diversification as prudent insurance rather than an emergency.

Exercise 36.15 †

(Guided — results vary.) The deliverable is one sentence naming the biggest gap. Expected observations: the engines often (a) disagree on the answer and the sources, (b) cite big publishers, directories, or a competitor rather than you, and (c) give a generic answer that misses the specific, experience-based detail only you have. Example sentence: "Two answer engines cited a national directory and a competitor but not us, and both gave the textbook answer while missing the one thing our customers actually need to know — [the local/experience-specific detail] — which is exactly the information-gain gap we should own and the reason to build the brand so people come to us directly." The point is to see who the engines trust today and what they can't answer — your citation target and your content opportunity.

Exercise 36.17

(Guided.) The deliverable is your single biggest rent-vs-own gap. Most sites discover the same thing: they have invested years in rented Google traffic and almost nothing in owned audience — no email list (or a stale one), no active review collection, no direct-relationship program. Example finding: "We get ~10,000 organic visits a month and have a 200-person email list we last emailed a year ago — our owned audience is ~2% of our rented traffic, which means one algorithm change could take almost everything. First project: turn the visit into a subscriber." The gap is the future-proofing to-do list.

Exercise 36.19

Query A ("how does a tankless water heater work"): high AI exposure (informational; a summary answers it), likely a continued soft decline in clicks even as the ranking holds. Most sensible response: keep the page but change its job — make it the cited source (§36.4), deepen it past the generic explanation to the "how to tell on your unit / what installers wish you knew" follow-up (information gain), and don't depend on its click. Query B ("tankless water heater installation [city]"): very low exposure (local/transactional; the local pack and a call win), clicks likely steady. Response: invest hardest here — this is the converting traffic; strengthen the local pack, reviews, and booking path (Ch 25). Fund B first; repurpose A.

Exercise 36.21 †

(Guided.) The deliverable is a funded priority with a reason. Expected reasoning: the transactional/local query shows little/no AI Overview and a dominant local pack or buy/book path — its clicks are resilient because an answer can't complete the action, so it is the safer, higher-converting investment and should be funded first. The high-volume informational query shows a full AI Overview and softening clicks despite volume — its traffic is exposed and converts poorly, so it should be repurposed (brand + citation + information-gain depth) rather than treated as a primary traffic bet. Fund the resilient converting query first; the big volume number on the informational query is a trap if AI is absorbing it and it never booked jobs anyway.

Exercise 36.23

Three reasons "AI Overviews mean SEO is dead" is too simple: (1) Retrieval — the Overview is built by retrieving from the ranked, indexed web, so the crawling/indexing/relevance/authority/trust work of SEO now also feeds the AI layer rather than being replaced. (2) Uneven exposure — transactional, local, navigational, and high-stakes queries still overwhelmingly produce clicks, which is most of the money for huge numbers of businesses. (3) History — "SEO is dead" has been declared after every major change (Panda, mobile, snippets, voice) and been wrong every time, because it mistakes a tactic changing for the discipline ending. What's true is narrower: answer-in-a-sentence content that only restated the consensus is genuinely threatened — and that was always the most replaceable thing you could publish.

Exercise 36.24 †

It echoes "guaranteed #1 rankings" because it sells certainty and control over a system you don't control. Nobody outside the companies building answer engines knows exactly how they select and cite sources; the systems are new, changing constantly, and differ from one another; so a repeatable "secret technique" is packaging correlation and guesswork as a method — the identical move the guaranteed-rankings crowd always made (Ch 11 guardrails, Ch 2 evidence tiers). What is evidence-supported about being cited: rank well (retrieval draws on the index), be clearly structured and directly quotable, be genuinely authoritative and widely referenced as an entity, and carry accurate, specific information gain. That is good SEO — no secret, and no guarantee (cited ≠ visited).

Exercise 36.25

Three genuinely-unknown things (any three): whether AI answers grow, plateau, or partly retreat; whether/how Google protects clicks to sources; how any of it gets monetized (for Google and for publishers); whether the answer-engine market fragments across many tools; whether users keep trusting AI answers or learn to scroll past them; what happens to the incentive to create original content. "We don't know" is more professional than a confident forecast because a confident forecast on an unknowable, fast-changing system is a guess dressed as insight — it invites betting the business on one scenario. The honest answer (a range of scenarios with updatable probabilities) leads to the right action: build for robustness, hedge with diversification, and update as evidence arrives.

Exercise 36.27

The argument: Google's AI Overviews are built by retrieving from the open web, so if Google starves publishers of traffic, publishers publish less, the open web decays, and Google's own answer engine loses the fresh, high-quality content it needs to have something accurate to summarize. Google therefore has a real self-interest in not killing the goose. This makes the bleakest "Google takes all the traffic" scenarios possibly self-limiting — there is a structural force pulling against total click capture. It is a reason for cautious hope, not complacency, because (a) the incentive is structural, not a promise — Google may misjudge the balance or move slowly — and (b) "possibly self-limiting" is not "safe," so you still diversify. Hope tempered by hedging is the honest posture.

Exercise 36.28 †

Rivertown's exposure diagnosis (like Figure 36.3): - Branded traffic ("rivertown home services"): very low exposure (navigational — they want Rivertown specifically). Implication: SAFE; it's most of today's ~8,000 visits; protect it by building the brand. - Local/transactional ("furnace repair cedar hills," "ac repair near me"): very low exposure (needs a real, nearby, accountable pro). Implication: THE MONEY; the whole local-pack/service×city goal is aimed here and is barely touched by AI. - Informational blog ("how long does a furnace last"): HIGH exposure (a sentence answers it). Implication: AT RISK — and it was never the traffic that booked jobs anyway. The verdict is reassuring because the exposure falls almost entirely on the low-value traffic, while the traffic that actually converts (local, transactional, branded) is the kind AI answers can't fulfill. A local service business is one of the best-positioned businesses in the AI transition — if it acts (leans into the resilient traffic and builds owned channels).

Exercise 36.29

Email is Rivertown's biggest owned-asset opportunity because it is the one channel with no algorithm between the company and its audience — Google can't put an AI Overview between Rivertown and its own subscribers, and every completed job is already a customer relationship worth keeping. For a home-services company, reminder-driven repeat work is high-margin, and email is how you trigger it. Two seasonal touches: (1) a fall furnace tune-up reminder ("book before the first cold snap; here's what we check"), and (2) a spring AC check reminder ("beat the summer rush; a 15-minute check now prevents a July breakdown"). Both convert a one-time caller into a recurring, owned relationship that doesn't depend on search at all.

Exercise 36.31 †

Rivertown's Google Business Profile reviews (Ch 25) are a moat an AI answer cannot copy because they are specific, verified, first-hand records of real customers' experiences with Rivertown specifically. An answer engine can describe, in general, what a good HVAC company looks like — but it cannot manufacture four hundred genuine, recent, well-answered five-star reviews of Rivertown, and it cannot substitute a generic description for the trust a local searcher places in that concrete evidence. Reviews are earned, local, dated, and attributable to real people — everything a generic summary is not. They also do double duty: a local ranking/trust signal (Ch 25) and a conversion asset and a diversification moat. The AI can answer "which company is good?" only by pointing at exactly the kind of reputation Rivertown is building — so the reviews both survive the AI layer and feed it.

Exercise 37.1

In-house — you own one organization's SEO as an employee (you own one site, deeply). Agency — you do SEO for many client sites (you own many sites in parallel). Freelance/consultant — you serve your own clients independently (you own your clients and your business).

Exercise 37.3 †

A scope of work is the explicit, written statement of what an engagement includes and excludes — deliverables, cadence, boundaries, and assumptions. It protects the practitioner from scope creep (the retainer that quietly becomes "do everything," from email design to answering the phone), and it protects the client from paying for a vague promise with no defined deliverables — they know exactly what they're buying and when.

Exercise 37.5

The non-SEO skills: communication, project management, data literacy, writing/editing, (enough) technical fluency, business acumen, and ethical judgment. The chapter calls communication the number-one differentiator — "not close" — because SEO that can't be explained to the people who control the budget doesn't get funded.

Exercise 37.7

The paths are three different lives, not rungs: in-house trades breadth for depth and stability; agency trades depth for breadth, pace, and mentorship; freelance trades security for autonomy and a higher per-hour ceiling — none is "the top." In-house is clearly right first for someone who wants stability and depth, dislikes sales, and wants to see one site's results compound over years (e.g., a mid-career person with a mortgage who loves ownership). An agency junior role is clearly right first for a fresh beginner who wants to learn fast, needs mentorship and someone to check their work, and benefits most from seeing many sites and problems in a short time.

Exercise 37.8 †

The pitch leaves out that freelancing is running a business, of which the SEO work is maybe half. Three responsibilities an employed SEO doesn't carry: (1) sales and pipeline — you must constantly find and close clients, and income is variable/feast-or-famine; (2) business operations — contracts, invoicing, chasing payment, taxes, and your own tools/benefits/retirement, all unpaid overhead; (3) being the whole brand and safety net — when you're sick or on vacation, nothing bills, and there's no employer buffering you from a difficult client. Freedom is real, but it's freedom with those obligations, not instead of them.

Exercise 37.9

Two reasons from the text: (1) an agency junior role puts you in front of many sites and problems fast — you'll see thirty situations in a year that would take years to encounter alone; and (2) you learn with senior people checking your work and mentoring you, so you build correct habits instead of self-taught misconceptions. The breadth-plus-mentorship combination is why it's the best first job for most beginners.

Exercise 37.11 †

It's a project-management failure because delivering a document is not the same as getting the work done — and getting work done through other people (developers, writers, leadership) is the core of the SEO job (§37.4). An audit that's admired and shelved created no value. What the SEO could have done differently: scope implementation support into the engagement (not just the audit), translate findings into prioritized, developer-ready tickets, secure buy-in from whoever controls the dev roadmap before delivering, and follow through on the tickets rather than assuming the report would act on itself.

Exercise 37.13

Even a purely technical SEO writes for a living, just not articles. Two artifacts: (1) the developer ticket / fix specification — a precise, unambiguous written brief ("these descriptions render only after JavaScript; we need them server-rendered") that gets a fix shipped correctly; and (2) the monthly report / findings document for non-technical stakeholders, where clear writing is the difference between the work being understood and funded or being ignored. Clear writing is clear thinking made visible, and both artifacts fail without it.

Exercise 37.15 †

Failure: scope creep, enabled by the absence of a written scope of work. With no defined in/out boundaries, the flat retainer has silently expanded to "do everything," so non-SEO tasks (email, ads, a broken form) are crowding out the SEO the client is actually paying for. Fix: introduce a written scope now — enumerate what the retainer includes and, explicitly, what it excludes (email, paid ads, general web fixes), and either re-price to add those as separate work or refer them out. Then reset expectations in a short call. The lesson is that the scope should have existed at signing; add it immediately and hold the line going forward.

Exercise 37.16 †

Almost certainly the agency hit the guaranteed deadline with manipulative link building (or similar spam), which produced a fast bump and then triggered a manual action for unnatural links (Chapter 26) once Google reviewed it — the JCPenney pattern (Case Study 1) in miniature. The performance/guarantee model forced the shortcut: you can't honestly guarantee a ranking, so meeting the guarantee meant gaming it. Who the client blames: the client blames themselves last and the SEO first — they won't credit their own impatience; they'll remember that traffic collapsed on the agency's watch, and they'll tell others. That reputational damage, in a referral field, is the real cost.

Exercise 37.17

Missing §37.4 skills: project management (recommendations never become shipped work — no tickets, no buy-in, no follow-through with the dev team) and communication (leadership has never seen a report, so the work is invisible and unfunded). The first move is not more SEO analysis — it's to make the work visible and actionable: write one clear report leadership will actually read (tie SEO to business outcomes, Chapter 29), and convert the top recommendations into prioritized, dev-ready tickets with buy-in from whoever owns the roadmap. Excellent recommendations that no one ships and no one sees are worth nothing.

Exercise 37.19

Hourly pricing ties income to hours billed, so getting faster and more skilled means each valuable outcome takes fewer billable hours — you're literally paid less for being better, a perverse incentive that also caps your income at your available time. Fixes: move to value-based pricing (price to the value delivered, not the clock), project/fixed-fee pricing (price the outcome/deliverable regardless of hours), or a retainer scoped to deliverables rather than hours. Any of these decouples your pay from the time spent and rewards efficiency instead of punishing it.

Exercise 37.20 †

(Guided — deliverable, not a fixed answer.) The deliverable is proof you completed at least the first module of a free tool-focused certification (the Google Analytics certification via Skillshop is recommended) plus two sentences on one genuinely useful thing you'll reuse. A model response: "The GA4 course clarified that GA4 is event-based, not pageview-based, so a 'conversion' is a key event I define — which changes how I'll set up a client's phone-call and form-fill tracking (Chapter 28). I'll use that immediately when configuring Rivertown's conversions." The point is to internalize that the value of the cert is the tool skill, not the certificate itself.

Exercise 37.21

(Guided — answers vary by site.) The deliverable is three specific, honest findings with a fix category each, e.g.: (1) "site: shows ~1,100 pages vs. ~200 expected → likely index bloat, an indexing issue (Ch 14)"; (2) "PageSpeed Insights mobile LCP ~4.8s on the homepage → Core Web Vitals / speed (Ch 16)"; (3) "Rich Results Test finds no structured data on the main service page → schema opportunity (Ch 18)." Keep them — this is the raw material of your first portfolio case study, and it mirrors the opening move of a real client engagement (a paid audit).

Exercise 37.23 †

This is an in-house role ("own our site," "report monthly to the leadership team," internal partners). The two lines telling you it's won on §37.4 skills rather than tools: "Partner with content, engineering, and product" (project management / cross-functional delivery) and "Report monthly to the leadership team" (communication to non-technical stakeholders). Note the tools are only "nice to have." In your application, answer those two lines directly: show a report you wrote for a non-technical audience, and describe a time you got another team to actually ship your recommendation — evidence of the load-bearing skills, not a list of tools.

Exercise 37.25

A model rewrite (illustrative numbers, labeled): "Scope — SEO retainer, \$2,000/mo (illustrative), 3-month minimum, then monthly. In scope: (1) monthly technical + on-page fixes specified for your developer; (2) keyword and content strategy with briefs for up to 2 pages/month; (3) local SEO for your locations (Google Business Profile, NAP cleanup, review process); (4) a monthly report tied to leads, not vanity metrics. Out of scope: paid advertising; website design/development (I specify, your team builds); high-volume content writing; social media; any guarantee of rankings. Honest expectation: meaningful non-branded gains typically take ~6 months and depend on your team shipping the fixes." The key upgrades: defined deliverables, explicit exclusions, a refused guarantee, and a realistic timeline.

Exercise 37.27 †

It's a myth because technical SEO requires understanding how a site works well enough to diagnose a problem and brief the person who fixes it — not the ability to build the site yourself. The actual level §37.4 requires: enough fluency to read what a site is doing and specify a fix precisely (e.g., "these product descriptions only appear after JavaScript runs, so Google isn't indexing them; we need them server-rendered," Chapter 19). Plenty of excellent SEOs can't code at all; the skill is diagnostic and communicative fluency, not programming. (The reverse is also a myth: being a strong engineer doesn't automatically make you a strong SEO — the strategy and communication still have to be learned.)

Exercise 37.29

You decline because you don't control Google's ranking decision or the client's competitors, so a guaranteed ranking is a promise you can only keep by luck or by manipulation that will later backfire on the client (rule one, §37.7; Case Study 2; Google's own docs say no one can guarantee a #1 ranking). What you offer instead: a defined, honest engagement — an audit, a prioritized fix and content plan, honest monthly reporting on leading indicators and business outcomes, and a reasoned expectation of gains over months. You promise the work and the method and improved odds, backed by evidence — never the outcome. The client who only wants the guarantee is signaling they'll be a bad client; losing that deal is cheaper than the disaster of trying to keep an impossible promise.

Exercise 37.30 †

(Guided — a model scope.) Structure: project-then-retainer — a fixed-fee audit first (low commitment; establishes the baseline and the prioritized punch list), then a monthly retainer for execution, because Rivertown's is a long-game, five-city problem a one-off can't carry. In scope (4): technical audit + fix specifications; local SEO for all 5 locations (Google Business Profile, NAP cleanup, review process); keyword/content strategy and on-page/internal-linking plan; analytics setup + a monthly report the owners actually read. Out of scope (4): paid advertising/PPC; website redesign/development (Rivertown's team or a contractor builds — the consultant advises); high-volume content writing (consultant briefs; a writer or the technicians draft with expert review); and any guarantee of rankings or the local pack. Honest expectations (3): no ranking guarantees; growth is in non-branded/"near me" queries and compounds over ~6–12 months, not weeks; success depends on Rivertown shipping the dev fixes and giving technicians time to review content. (No budget/ROI — that's Chapter 39.)

Exercise 37.31

A model sentence: "This plan's results depend on Rivertown's team shipping the specified developer fixes on a reasonable cadence and giving technicians a few hours a month to review content for accuracy — without that implementation, the recommendations can't move the numbers." Leaving this sentence out is a common way engagements fail because it lets the client believe SEO is something done to them rather than with them; when the fixes sit unshipped and results don't come, they blame the SEO rather than the un-actioned recommendations. Naming the client's obligation up front converts a future argument into a shared, agreed condition of success.

Exercise 38.1

The five lenses, each with its question and pipeline stage(s): Technical — "Can Google find, crawl, render, and index this site at all?" (discover → crawl → render → index). On-page — "Does each page match the intent behind its query and win the click?" (rank / serve). Content — "Does the library as a whole deserve to rank — any thin, duplicate, or cannibalizing pages?" (rank). Off-page/authority — "Does the rest of the web vouch for this site, and is any of the link profile a liability?" (rank). Competitive — "What do the sites already winning these SERPs have that we don't?" (runs across all lenses, because ranking is relative).

Exercise 38.3 †

A technical audit checks whether Google can process the site — crawl, index, speed, mobile, render, structure. A content audit checks whether the site's pages, individually and as a library, deserve to rank — intent match, comprehensiveness, and the keep/update/merge/delete decision on thin/duplicate pages. An authority audit checks whether the wider web vouches for the site through links, and whether any of the profile is a liability. You run the technical lens first, because it interrogates the earliest pipeline stages: a page that can't be crawled or indexed can't be helped by better content or more links, so a technical block gates everything downstream (theme 4).

Exercise 38.5

The four quadrants and their one-word verdicts: high impact / low effort → "first" (quick wins, do this week); high impact / high effort → "schedule" (major projects, resource them); low impact / low effort → "batch" (fill-ins, do when idle); low impact / high effort → "decline" (thankless tasks, usually don't).

Exercise 38.7 †

An unprioritized 200-item audit has done the easy ninety percent of the job — finding things wrong, which anyone can do to any site — and skipped the hard, valuable ten percent: deciding which handful of things to do first. It fails even when every finding is correct because it actively misleads: it invites the owner to work top to bottom, spending time on trivia while a high-impact, gating problem (say, a noindex hiding real pages) sits unnoticed in the middle. The count of findings is a vanity metric; the ordering is the product. The hard 10% the checklist dump skips is prioritization — scoring each finding by impact × effort and sequencing it into a plan (and a short one: a great audit might have 100 observations and a five-item action list).

Exercise 38.9

The Rivertown example is the ~40 inherited footer-spam domains: audited, carrying no manual action, and already ignored by Google's systems (SpamBrain). The correct finding is "document and monitor; do not disavow." Acting on it — disavowing the links — would be worse than leaving it alone because disavowing carries real downside (you might catch a borderline-legitimate link and remove a genuine signal) while buying zero upside (Google already ignores the spam, so there is no penalty to lift and no ranking to gain). A finding can correctly end in "do nothing," and reflexively "cleaning up" is less disciplined, not more.

Exercise 38.10 †

When a practitioner presents a prioritization matrix as if its rankings were precise, they imply a certainty that does not exist: they can't know a fix will lift traffic by a specific amount, because Google decides rankings against competitors they don't control. Overstating precision leads to brittle plans (and to broken promises when the "predicted" gain doesn't land) and it disguises judgment as measurement — the opposite of the book's evidence-over-folklore posture. The honest auditor estimates impact from evidence (a page with 12,400 existing impressions has provably more upside than one with 30) and effort from experience, and labels both as best-judgment estimates to be revisited as they learn — the matrix is a tool for sequencing under uncertainty, not a formula that removes it.

Exercise 38.11 †

Because the highest return is a function of both axes, and a good page just off page one wins on both. On the impact axis, it already has a proven audience — Google shows it, its impressions are real — so lifting its position converts existing demand rather than trying to create demand from nothing (the position-45 page has no audience yet). On the effort axis, it needs a few specific, already-diagnosed fixes (an intent-matched title, internal links, closing a content gap), not a ground-up rebuild. High impact and low-to-medium effort put it squarely in the quick-win / flagship zone. The site's worst page, by contrast, is usually low impact (no audience) and high effort (needs everything) — the thankless quadrant.

Exercise 38.13 †

Sequence by impact × effort: First (quick wins, this week): (a) the stray noindex hiding four service pages — high impact (real pages invisible), low effort (uncheck/remove) — and (e) the high-impression, low-CTR page with a generic title — high impact (existing audience), low effort (one edit). Next (schedule): (c) the homepage mobile LCP of 4.5s — meaningful impact, medium effort (caching/CDN may be a quick win, image work is a project). Batch when idle (fill-ins): (b) 22 missing meta descriptions — low impact (meta isn't a ranking factor; only a CTR nudge), low effort. Probably don't / defer: (d) sitewide breadcrumb schema — low-to-modest impact, higher effort; nice-to-have, not a priority. Do a and e now; do the rest in that order.

Exercise 38.15 †

They differ because effort differs enormously while both are high impact. (b) Removing the accidental noindex on the five pages is high impact, low effort — a few minutes to uncheck a box or delete a tag, and five real pages rejoin the index. It is a quick win and must come first. (a) Rebuilding the five thin location pages into genuine local resources is high impact, high effort — original local content, addresses, photos, reviews, per page — a major project to schedule and resource. The order is forced: there is no point rebuilding pages that are still hidden by noindex, and even if there were, you always take the high-impact/low-effort win before the high-impact/high-effort project. Same impact tier, opposite quadrants, because effort decides.

Exercise 38.17 †

(Guided — results vary by site.) The deliverable is three recorded findings with impact tags. Example: "Non-200 URLs: 9 (six 404s, three 301 chains) — medium impact, low effort → 301 the valuable 404s, flatten the chains. Duplicate/missing titles: 40 pages share one templated title — medium-to-high impact, low-to-medium effort → write unique titles for priority pages. Deepest important page: a key service page at crawl depth 6 — medium impact, medium effort → link it from a hub to bring it within ~3 clicks (Chapter 15)." The point is to record each finding with an impact estimate, not just to list problems.

Exercise 38.19

(Guided.) Record field LCP/INP/CLS for three key pages; note any "insufficient field data" (common on low-traffic pages — itself a visibility finding, not a speed one). Then judge impact by traffic: the worst-scoring page is only a high-impact fix if enough people visit it to matter. A homepage at LCP 4.5s with heavy traffic is a higher priority than a rarely-visited page at LCP 6s. Core Web Vitals is a tiebreaker, not a magic bullet (Chapter 16), so weight the fix by the audience it affects.

Exercise 38.20 †

(Guided.) The Manual Actions report says either "No issues detected" (the common, reassuring case) or it lists a specific manual action. This single report outranks any third-party "toxicity" or "health" score as penalty evidence because it is Google's own verdict — the actual mechanism by which Google penalizes a site — whereas a tool's score is a vendor's heuristic guess built from data Google doesn't share. If Manual Actions is clean, you are not penalized, full stop, no matter what a tool's dashboard implies.

Exercise 38.21

(Guided.) Identify one page with high impressions, low CTR, and average position 5–15 — the classic on-page opportunity. The single cheapest first fix is almost always the title tag (and secondarily the meta description): the page already ranks and is seen, so a more compelling, intent-matched title can lift CTR with no new content and no waiting (Chapter 9). Only if the title is already strong do you look at intent match or comprehensiveness.

Exercise 38.22 †

The opportunity is a high-impression, off-page-one page — the same shape as the page stuck at #11. The crawler's clean bill of health (200, indexable, unique title, 1,900 words, depth 2) confirms the page is technically fine, which is exactly why a crawl-only audit misses it: a crawler has no idea whether a technically-healthy page is winning. Search Console reveals the truth — 8,700 impressions but only 95 clicks at average position 9.4 — meaning a real audience is one page-turn away and the page just isn't converting impressions to clicks or isn't quite ranking high enough. The on-page/content lens, reading Search Console (not the crawler), surfaces it. The fix: sharpen the title/meta for CTR and close the content gap against the pages ranking 1–5, to earn the higher position and the clicks.

Exercise 38.23

A good rewrite drops the count and the score and leads with prioritized actions, e.g.: "Your site is technically sound, with three high-return opportunities this quarter. (1) Remove the noindex currently hiding your four service pages — this alone should restore their visibility [quick win, do this week]. (2) Rewrite the title tag on your top-impression guide, which ranks position 8 but earns few clicks [quick win]. (3) Rebuild your thin location pages into genuine local resources [major project, schedule for Q2]. The remaining 93 findings are minor and listed in the appendix; none is urgent. This plan improves the odds of ranking; it does not guarantee a result." Lead with the few things that matter, in plain language, with impact and effort — not "96 issues, score 58, fix everything."

Exercise 38.24 †

Lens: technical (indexation) with a content dimension. Impact: high — five near-duplicate pages compete with each other for the same local queries, and none is strong enough to win. Effort: high — the real fix is differentiation, i.e., a major project. Recommended action: rebuild each location page into a genuinely distinct local resource (real address, local content, photos, reviews) so the five stop being near-twins (Chapters 15, 25). "Add a canonical tag" is not the right fix because canonicalizing four of the five to one would tell Google to ignore four real location pages — the opposite of the goal, which is to make all five rank in their own cities. The pages don't need consolidating; they need differentiating.

Exercise 38.25

Two separate false claims. (1) "Your SEO health score is 64/100" used as a verdict — the score is a vendor's weighted sum of automatically-checkable items, not Google's opinion; getting it to 100 optimizes for the tool, not the searcher, and measures nothing about intent, authority, or the relative contest that decides ranking. Truth: read the individual findings, ignore the composite grade. (2) "…guarantee first-page rankings" — no honest practitioner can guarantee a ranking; ranking is Google's decision against competitors you don't control. Truth: an audit improves the odds by directing effort at the highest-return work; it never promises an outcome.

Exercise 38.26 †

Walk the honest decision: (1) Check the Manual Actions report first — it's the only authoritative penalty signal. Here it's clean ("No issues detected"), so the site is not penalized. (2) Recognize that "toxic" is a tool heuristic, not a Google verdict, and that Google already ignores most spammy links automatically (SpamBrain). (3) Weigh disavow's cost/benefit: it risks catching a borderline-legitimate link (downside) and buys no ranking gain when Google already ignores the spam (no upside). Likely correct action: do not disavow; document the finding and monitor. Disavow is a rare tool, reserved mainly for cases with an unnatural-links manual action you must clean up (Chapter 26).

Exercise 38.27

Yes — the short, honest recommendation is the professional one. An audit's purpose is to direct finite effort at the highest-return work, which sometimes means recommending less: "your links are fine, leave them alone" saves the client from spending time and risk (a needless disavow) to gain nothing. Padding the report with make-work to appear thorough betrays the client's interest for the appearance of value — the checklist-dump failure with a profit motive. The consultant's credibility rests on being willing to say "don't do that," and a recommendation to not act, backed by evidence (no manual action; Google ignores the links), is as much a deliverable as a to-do list. Honesty about what not to do is the service.

Exercise 38.29 †

Place each Rivertown finding: (a) Millhaven noindex — high impact (real pages hidden), low effort (uncheck the box) → quick win, this week. (e) no caching/CDN — high impact (cuts TTFB on every template), low effort → quick win, this week. (c) the #11 water-heater page — high impact (12,400 impressions, one page from traffic), medium effort (title + links already done; write the nine subtopics) → flagship, ★. (b) thin, near-duplicate location pages — high impact (blocks local pack and service×city), high effort (rebuild five pages) → major project, schedule. (d) ~40 inherited footer-spam domains — no manual action, Google ignores them → no action, on purpose; document and monitor. Working order: a and e now; the #11 page as the flagship; the location rebuild scheduled; the links left alone.

Exercise 38.31 †

(Guided — this is the reader's own audit.) The deliverable is a one-page prioritized audit of their site: all five lenses run with free tools (a crawl, Search Console's Page indexing / Performance / Manual Actions, PageSpeed Insights, one competitor SERP read), every finding scored by impact × effort, sorted into the four quadrants plus a "no action" list, and topped with a three-line executive summary naming the top three actions this quarter. Recorded in Appendix C's Worksheet 5 against Appendix G's checklist, this is the artifact the reader carries into the Chapter 40 capstone. A complete answer names at least one quick win, one scheduled major project, and — the discipline check — at least one finding deliberately marked "no action."

Chapter 39 — Worked Solutions (daggered † and odd-numbered exercises)

All figures illustrative, as in the chapter.

Exercise 39.1

Organic value = organic traffic × conversion rate × value per conversion, and SEO ROI = (organic value − SEO cost) ÷ SEO cost. Factors: organic traffic — unpaid search visits (itself impressions × CTR); conversion rate — the share of visitors who take the valuable action (call, form, booking, purchase); value per conversion — average revenue (or lead value) per conversion, conservatively the first-transaction value and more fully the customer lifetime value; SEO cost — everything spent to earn the traffic (strategy, content, technical, links, local, tools).

Exercise 39.3

Value per conversion changes because a customer is usually worth more than one transaction: first-transaction value counts only the opening invoice, while customer lifetime value (CLV) counts the whole relationship — repeat jobs, maintenance plans, referrals. A conservative business case should use first-transaction value, because it survives scrutiny and understates rather than overstates the return; CLV is then presented as the upside that makes the real return higher than the model shows.

Exercise 39.5

An expense is consumed and gone (you pay for the click, you get the click, transaction closed); an asset is built once and keeps producing value over time. SEO more closely resembles an asset — a ranking page keeps earning, content compounds, authority accrues. The caveat: the asset depreciates without maintenance (content decays, competitors invest) and sits on a platform you don't control (an update can revalue it), so it is an asset with upkeep and risk, not a risk-free perpetuity.

Exercise 39.7

(a) ΔVisits ≈ 1,500 × (0.07 − 0.016) = 1,500 × 0.054 = ~81 incremental visits/month (illustrative). (b) 81 × 4% = 3.24 leads → × 50% close = 1.62 jobs → × \$500 = **~\$810/month** of incremental organic value at the target run rate (~\$9,700/yr). Every figure illustrative; the target position is not guaranteed.

Exercise 39.9

• Paid does better: it is instant and precisely controllable/testable — live today, targetable to one city, useful to validate which offers convert. When you need booked jobs this week, ads deliver while SEO warms up.
• SEO does better: durability — it builds an owned, compounding asset that keeps producing after spend slows, at near-zero marginal cost; paid stops the day you stop paying.
• Why both: they are different maturities of the same investment. Fund paid for immediate demand and testing; fund SEO in parallel to steadily lower how much you must rent. The honest line: "Keep buying the demand you need today; let's also build the asset that makes us need to buy less of it every year."

Exercise 39.10

ROI = (135,000 − 83,000) ÷ 83,000 = 52,000 ÷ 83,000 = ~63% (illustrative). It likely understates the true return because it uses conservative first-job value (not CLV), it charges the entire one-time technical build against year one, and the month-12 run rate (~\$33k/mo, ~\$400k annualized) carries into year two against a far lower maintenance cost — so a one-year snapshot misses the compounding.

Exercise 39.11

SEO's cost is front-loaded to build an asset (pages, fixes, links, authority) with low marginal cost afterward, so as the asset produces against maintenance-only cost, cost per acquisition falls toward near-zero. Paid rents each click, so its CPA is set by the ongoing per-click price and stays roughly flat forever — "you stop paying, it stops," versus "you built an asset that keeps producing."

Exercise 39.13

"Right now you treat SEO as an expense — money spent and gone, like an ad click you have to buy again tomorrow. But a page that earns its way to ranking is an asset: you build it once and it keeps producing customers for months and years, at almost no marginal cost, the way an owned building keeps producing rent. So the honest question isn't 'what did this month's spend buy this month?' — it's 'what durable asset are we building?'" The concession: the asset depreciates without maintenance and can be revalued by a Google update you don't control, so it needs upkeep and carries real risk — it is an appreciating asset, not a risk-free bond.

Exercise 39.15

First confirm the four upstream stages are genuinely fine (Chapter 1): is it truly indexed, crawlable, rendered? "Technically healthy" is the premise, so move to the ranking contest. Check intent match (Chapter 3) — does the page match what the searcher wants, or is it a mismatch? Check on-page (Chapter 9) — does the title answer the query, is the page comprehensive versus the result that outranks it? Check authority/internal links and the competitive gap (Chapter 38's audit). Then estimate the term's volume and a realistic target position, and forecast the incremental visits with the CTR-delta method. What the business case can promise: a modeled range of value if the page reaches the target position, and an honest estimate of the effort. What it cannot promise: that the page will actually reach that position — Google ranks it, not you — so the forecast is a scenario, never a guarantee.

Exercise 39.16

Guidance: expect your real CTRs to differ — sometimes sharply — from the chapter's illustrative table. Brand queries can show very high CTR at any position; queries buried under ads, a local pack, or an AI Overview can show far lower CTR than the table implies even at good positions; and CTR varies by device and query type. That variance is exactly the point: a borrowed table is non-representative, while your Search Console figures are your ground truth from Google. Forecast with your own curve; use the illustrative table only to understand the shape.

Exercise 39.17

Model approach: rank by opportunity = value × winnability, not by volume. A high-volume, high-difficulty, low-CPC term is often top-of-funnel — hard to win and low commercial value — so it ranks lower for a business case despite its traffic. A modest-volume, lower-difficulty, high-CPC term (CPC signals advertisers pay for it, i.e., it converts) is often the best forecast input. Justify each ranking by naming which of the three signals drove it and how intent shaped the expected conversion.

Exercise 39.18

Model rewrite: "Rivertown is invisible for the searches that bring new customers — an illustrative six-figure-a-year opportunity in booked jobs we're currently handing to competitors. Here's what capturing it costs, when it pays back, and how we manage the risk." What changed: the opening now leads with the business outcome (revenue, opportunity cost) in the language the CFO evaluates, instead of tactics in jargon (title tags, canonicals, schema, CWV) that half the room can't price. The tactics belong later, as the how, never as the opening line.

Exercise 39.19

Compute the leads, not the visits: commercial term = 70 visits × ~5% = ~3.5 leads/mo; informational term = 168 visits × ~1% = ~1.7 leads/mo. The commercial term produces roughly twice the leads from a quarter of the traffic, so it belongs higher in the business case. The higher-traffic term is not the higher-value one because intent differs — the informational searcher has a cold house, not a credit card out; it is top-of-funnel (real, but weaker, value: awareness, brand, occasional conversion), so it must be weighted by its low conversion, not its volume.

Exercise 39.20

Three questions before believing "412% ROI": (1) What attribution model produced it, and does it credit organic for conversions it only assisted or that would have come via brand anyway? (2) What counts as "organic value" — first-transaction revenue, customer lifetime value, or gross margin — and is it a defended range or a single confident point? (3) What is the counterfactual/baseline — what would have happened with no SEO — and over what horizon? The two inputs most likely inflated: value per conversion (quietly using CLV or gross revenue instead of margin) and attribution (over-crediting organic). A precise ROI delivered with a straight face is a claim to a certainty that doesn't exist.

Exercise 39.21

The myth is that unpaid-per-click means cost-free. Truth: organic clicks aren't billed per click the way ads are, but the traffic is bought with content someone wrote and an expert reviewed, technical fixes a developer shipped, links a business earned, and months of patience. "Free traffic" framing causes under-funding and quitting in month four; the honest framing is that SEO is an investment with a real, largely up-front cost and a delayed, compounding return.

Exercise 39.22

The myth is set-it-and-forget-it. Truth: SEO is ongoing because content decays, competitors keep investing, and the platform shifts under you (core updates, AI Overviews). Cutting the budget to zero lets the asset depreciate and the company then concludes "SEO doesn't work." The correct model is a sustained investment that steps down after year one — when the one-time technical build is finished — to a lower maintenance-and-growth level, but never to zero.

Exercise 39.23

Factually, no one can guarantee a ranking (Google ranks the page, and rankings depend on competitors and updates outside anyone's control) or a specific ROI (which depends on those same rankings plus conversion and market factors). Ethically, "guaranteed #1 / 300% ROI" is the snake-oil pitch this book exists to refute — it sells a certainty that doesn't exist. An honest pitch promises method, effort, honest forecasting in ranges, and transparent reporting — improving the odds and earning a result — never the result itself.

Exercise 39.24

Agreeing to a bare 90-day trial works against the client because SEO returns are back-loaded on a J-curve: 90 days ends inside the flat "valley of doubt," months before the payoff, so the client pays for the entire build and quits the day before it would start paying off — guaranteeing they waste their own money and wrongly conclude SEO failed. Restructure honestly: ask for a 12-month commitment with monthly reporting against the forecast and clear leading indicators (indexed pages, rankings for priority terms, early conversion signals — Chapter 29), framing anything shorter as setting the money on fire. If the client can only commit to 90 days, be explicit that it is not a fair test.

Exercise 39.25

No — presenting a single confident number as if it were certain is dishonest when the real figure is a modeled range with substantial uncertainty. The honest alternative: present the range with its assumptions and attribution model disclosed ("roughly 40–90% in year one under these inputs; here's what would move it"). It is more persuasive, not less, because it sounds like every other serious investment a board evaluates — ranges, payback, risk, honesty — rather than the guaranteed-return pitch experienced decision-makers have learned to distrust.

Exercise 39.26

Model 30-second pitch: "Marisa, Tony — we're invisible for the searches that bring new customers to all five branches, which on conservative, illustrative numbers is roughly \$400,000 a year in booked jobs we're leaving to competitors. Capturing it costs about \$83,000 in year one, breaks even around month ten or eleven, and — because it builds an asset rather than renting clicks — should return far more in year two at a fraction of the cost. It's not guaranteed and it depends on Google, so we diversify and we report to you monthly. I'm asking for a twelve-month commitment, because a ninety-day test would quit right before it pays off." (Opens with money and opportunity cost; ranges, not promises; the ask is the right horizon.)

Exercise 39.27

Millhaven needs jobs this quarter, so lead with paid search there now: it delivers booked jobs immediately while SEO is still warming up, and its high per-job cost is worth paying for demand you need today. Simultaneously start SEO in parallel for Millhaven (local pack, service×city pages) as the asset that will lower paid dependence over the next 6–12 months. Justification: timing (SEO can't produce this quarter) and ROI (accept paid's higher CPA short-term for speed; build the compounding asset for durable, cheaper demand later). This is the both/and of §39.3, applied to one branch.

Exercise 39.29

The "ac repair rivertown" page produces ~1.6 booked jobs/month (illustrative). At first-job value (\$700):** ~\$1,120/month ≈ \$13,000/year.** **At CLV (\$2,500): ~\$4,000/month ≈ **\$48,000/year — nearly four times as much, because home-services customers return for other trades, sign maintenance plans, and refer neighbors. Put the first-job figure (\$13k) in the pitch** as the conservative, scrutiny-proof number, and **hold the CLV figure (\$48k) in reserve as the honest upside that explains why the real return exceeds the model.

Exercise 39.30

• Chapter 7 supplies the organic-traffic input's raw material: search volume, keyword difficulty (winnability), and CPC (a commercial-value proxy) — the numbers that feed the traffic forecast (§39.2).
• Chapter 28 (GA4) supplies the conversion rate and value per conversion: the actual measured rates at which organic visitors call, fill forms, and book, and what those conversions are worth — replacing the model's assumptions with real data.
• Chapter 29 supplies the delivery: it turns the identity into an ongoing report with the KPIs that matter (not vanity metrics), sets expectations about the long game, and is where the business-case narrative is communicated month to month.

Exercise 39.31

The opportunity-cost argument: while Rivertown waits, the competitor's investment compounds — each month it earns rankings, reviews, links, and local-pack presence that get harder and more expensive to displace the longer they stand. Put it in money: if the metro's organic new-customer demand is worth an illustrative \$400k/year, ceding it means not only \$400k of forgone bookings annually but a future reclamation cost far higher than leading now, because you'd be dislodging an entrenched incumbent rather than competing on open ground. The cost of inaction — the value forgone plus the rising price of catching up — is often the part of the case that actually moves owners.

Exercise 39.32

Honestly advise against SEO (or paid-first) when: (1) the business needs customers immediately and can't survive the 6–12-month ramp — a new location or a cash crisis is a paid-search problem, not an SEO one; (2) there is essentially no organic search demand for what they sell (a brand-new category nobody searches for yet) — you can't capture demand that doesn't exist, so demand-generation or paid/social fits better; (3) the business can't or won't fund a sustained program — a half-funded six-month effort builds the asset and then abandons it, the worst outcome; (4) the fundamentals are broken — if the site can't convert, the product is uncompetitive, or reviews are terrible, more organic traffic just pours water into a leaky bucket; fix the bucket first. Recommending against your own service when it's the wrong fit is the strongest possible signal of the honesty that wins long-term clients.

Ch 40 — Worked solutions (daggered † and odd-numbered exercises)

Exercise 40.1

An SEO strategy document is the single artifact stating a site's situation, prioritized work, order and owners, measurement, and honest limits. A roadmap is that work sequenced into dependency-respecting, time-boxed phases with milestones and owners. A milestone is a checkable marker of progress, best framed as a leading indicator. An execution plan is roadmap + owners + budget + cadence — the answer to "who does what, in what order, and how will we know it worked?" A roadmap differs from a flat to-do list because it honors dependencies and time — items are ordered by what must come first (technical before content; architecture before the pages that live in it), not simply listed.

Exercise 40.3

Because you cannot plan a route without knowing where you are standing. Leading with content or the local-pack win assumes you already know what is broken and why; leading with the diagnosis (which pipeline stage is each problem?) makes every later section a response to a named problem rather than a generic best-practice checklist. It also prevents wasted work — Rivertown's diagnosis showed the demand was already there (~190k non-branded impressions) and the gap was rankings-and-listings, which reframes the entire plan from "get discovered" to "get chosen."

Exercise 40.5

A leading indicator moves before the business result; a lagging indicator is the business result confirming after the fact. From Rivertown: leading — impressions, average position on priority terms, indexed pages, review count, Core Web Vitals status. Lagging — organic booked jobs, revenue, and (largely) non-branded organic sessions once they convert. You judge a young program early by its leading indicators (they stir first) and late by its lagging ones, because judging only lead volume in month two would kill the program in the Phase-1 valley before the curve turns.

Exercise 40.7

Order to work them: (b) the live noindex → (d) the phone-as-image → (a) index bloat → (c) near-duplicate location pages. (b) first: a live noindex actively hides pages you want to rank; critical impact, minutes of effort — the highest-value hour on the list. (d) second: for an emergency home-services site, a non-tappable number blocks the exact action every mobile searcher wants; minutes of effort, high impact. (a) third: index bloat is a real quality/crawl-efficiency drag but lower-stakes, and a medium-effort cleanup. (c) last of these: fixing near-duplicate location pages is genuinely important but is content differentiation (higher effort, and it belongs to the local/architecture build), not a quick technical toggle. Triage by danger, then impact × effort.

Exercise 40.9

Technical argument: the site still has an accidental noindex hiding real pages, index bloat diluting the quality signal, and no clean architecture — publishing twenty posts onto that foundation is pouring water into a bucket with a hole in it; much of the new content won't be crawled, indexed, or linked well enough to rank. Content-strategy argument: volume is not a ranking factor ("post daily" is a myth, Ch 8); twenty un-prioritized posts risk cannibalization and rebuild the exact thin blog Ch 12 taught us to prune. The right sequence fixes the foundation and prunes first (Phase 1), then publishes a prioritized, single-intent cluster (Phase 2).

Exercise 40.10

The Cost Report must exist before you can pitch it — the outreach (digital PR, resource-page placement) is promotion of the asset, so scheduling outreach before the asset is finished would mean pitching something that isn't there. Another respected dependency: the site architecture (hubs, clean URLs, internal links) must be built before the service×city pages that live inside it, because those pages need a hub to hang off and links to flow authority to them — building the pages first would just create more orphans.

Exercise 40.11

Rule 0 — subtract first: do not auto-build all ~75 cells. Score each service×city cell by (a) real search demand and (b) whether Rivertown has a genuine local story/presence there; build the strong cells first (highest-demand services in every city) and skip or merge the rest — ~40 real pages beat 75 with 35 thin ones. The pre-publish gate: no page ships unless it says something true and specific about this service in this city that a find-and-replace could not produce (the branch, named techs, that city's climate/building reality, local reviews, permit/response detail). If it fails the gate, it is a doorway — don't ship it.

Exercise 40.13

Two most likely gaps: intent/format mismatch (the SERP is local pack + competitor service pages, so a thin or blog-style page won't compete — the page must be a genuine local service page matching transactional-local intent) and local signals/prominence (a page-three organic position with a local-pack-dominated SERP means the real fight is partly the pack, driven by the Google Business Profile, reviews, and proximity). Disciplines: on-page + local content (Ch 9, 25) to make the page a real, locally-specific service page, and the local-pack playbook (Ch 25 — GBP, reviews, NAP) because content alone will not win a pack-dominated SERP.

Exercise 40.15

A great page wins localized organic (the classic listings below the map) but not the pack, because the local pack is a separate contest driven by the Google Business Profile, proximity (how close the searcher is to a branch), and prominence (reviews, citations, links) — not by page quality. For "AC repair Millhaven," if the searcher is far from any Rivertown branch, proximity alone can keep Rivertown out of the pack no matter how good the page is. What actually helps: a claimed, complete, well-reviewed Google Business Profile for a branch that genuinely serves Millhaven — and, honestly, having a real presence close to those searchers. The page earns organic; the profile and proximity earn the pack.

Exercise 40.16

Plain-language answer: "The first three months are mostly repairs and cleanup, not new pages — on purpose. Right now Google literally can't see some of your service pages (a setting was hiding them), your site is slow on phones, and the pages you have aren't linked together so Google can find and trust them. If we publish a stack of new content on top of that, most of it won't get found or ranked — it's like installing new fixtures before you fix the leaking pipe. So Phase 1 fixes the pipe: we make the site fully visible, fast, and organized. Then, from month four, everything we publish lands on solid ground and actually has a chance to rank."

Exercise 40.17

Reframe: "It means we're being straight with you, and that's exactly what should make you more confident. Anyone who promises you a specific ranking on a specific date is either guessing or lying — Google decides rankings, against competitors we don't control. What we can promise is a plan grounded in evidence, done in the right order, with someone accountable for each piece, and measured against a baseline every month. The honest range and the named risks are what a real professional gives you. The guaranteed #1 is what the last guy gave you — and look how that went."

Exercise 40.19

Title: "Furnace Not Blowing Hot Air? Common Causes & Fast Fixes | Peak Comfort Heating & Air" — leads with the searcher's exact problem and promises the answer, brand last. Meta description (~150 chars): "Furnace running but blowing cold or lukewarm air? Here are the most common causes, quick checks you can do, and when to call a licensed tech — same-day service available." It sells the click by naming the problem, promising quick checks (informational intent), and offering the service (the conversion path) without keyword stuffing.

Exercise 40.21

Two legitimate new spokes for the "furnace problems" pillar: (1) "Furnace keeps shutting off after a few minutes" — primary intent: informational/diagnostic. It does not cannibalize "furnace short cycling" only if written as the plain-language symptom version that links to the short-cycling spoke rather than duplicating it; if it would duplicate, merge instead. (2) "How often should you replace a furnace filter?" — primary intent: informational/how-to (maintenance). Distinct from every existing spoke (none covers routine filter maintenance) and a natural internal link to the tune-up/maintenance service. Both pass the one-intent check and route any transactional demand to the service pages.

Exercise 40.22

Matrix: 3 services (bath, nail trim, de-shedding) × 3 neighborhoods = 9 cells. Rule 0: build only cells with real demand and a real local story. Likely build first: "dog grooming [neighborhood A/B]" where the business actually operates most and can name real specifics (routes served, a local park partnership). Skip/merge: a "nail trim [neighborhood C]" standalone page if demand is negligible and there's no genuine local detail — fold nail trim into the main service page and cover neighborhood C on a single "areas we serve" page until demand justifies more. Justification per cell is one line: real demand? real local story? If either is "no," don't build a standalone page — it would be a doorway.

Exercise 40.23

The five KPIs (proves / doesn't prove): Organic sessions, esp. non-branded — proves reach is growing among new customers / doesn't prove they converted. Organic conversions (calls, forms, bookings) — proves business value / doesn't count local-pack calls or confirm the lead was real or booked. Priority terms on page 1 — proves ranking progress on the terms that matter / doesn't equal traffic (a leading indicator). Pages indexed vs. real pages — proves Google is keeping the right pages after pruning / doesn't prove they rank. Mobile Core Web Vitals — proves the experience hurdle is clearing / doesn't drive rankings much (a tiebreaker).

Exercise 40.25

"A money-back guarantee on rankings sounds like confidence, but it's the opposite — it's a tell. No one controls Google's rankings; they depend on competitors nobody controls and on the searcher's own location and device, so 'guaranteed page one' is a promise about something the promiser can't deliver. The way these guarantees usually 'work' is by ranking you for terms so easy or so obscure that no customer searches them, then pointing at the 'ranking' — or by using risky tactics that can get your site penalized after the check clears. What an honest partner offers instead: a defensible plan, ranges not guarantees, named risks, monthly measurement against a baseline, and the truth about what's working and what isn't."

Exercise 40.27

Schema (LocalBusiness on the five pages) made the pages' meaning explicit to Google — the business name, address, phone, hours, and area — and reinforced NAP consistency, feeding the brand entity. It did not put the business in the local pack, is not a direct ranking factor, and does not produce review stars by itself. The local pack is driven by the Google Business Profile, proximity, and prominence (reviews, citations, links). Schema sits underneath the local system as support; the profile and reviews are the levers. Confusing "we added schema" with "we did local SEO" is a common and costly category error.

Exercise 40.29

"I hear you, and I get why it's tempting when a competitor seems to be winning that way. But buying links is a risk Google is very good at punishing — through Penguin, SpamBrain, and human reviewers — and the businesses that took that path, including big, well-resourced names like JCPenney and Interflora, got caught and lost their rankings overnight when they could least afford it. Even when it 'works,' the gains erode and the downside is catastrophic and abrupt. Your competitor may be sitting on a liability that hasn't detonated yet. The good news is you don't need it: your real relationships — chambers, suppliers, sponsorships — and a genuinely citable data asset earn the links that last and that no update reverses. It's slower. It's also the only version that compounds instead of collapsing."

Exercise 40.31

Report it — on both grounds. Ethically: honest reporting means including what didn't work; hiding the flop is a small deception that erodes the trust the whole relationship runs on. Strategically: the flop is data — six "how HVAC works" posts drew no traffic because they were the wrong intent (informational, low commercial value), so the honest report redirects that effort to service/transactional pages that convert, which is a better plan. And the blemish makes the wins believable: an owner who sees you report a miss trusts your reported wins, and that trust is what funds year three. A report that only ever shows green is a report no one believes.

Exercise 40.32

Honest recommendation: don't fully parallelize; compress selectively. What breaks if you run Phases 1 and 2 at once: you'd be building and publishing service×city and cluster pages onto an architecture, schema layer, and index-cleanup that aren't finished — recreating orphans and thin-signal exposure, the exact foundation problem the phasing exists to prevent. What can legitimately be accelerated in parallel: the local-pack groundwork (claiming/verifying the five Google Business Profiles, starting the review engine, NAP cleanup) has few technical dependencies and can begin during Phase 1, and the data-asset build can start early since it depends on invoices, not the site. So: keep the technical foundation sequenced first, but pull the profile/review and asset work forward. Set the honest expectation that six months is aggressive and the compounding still needs the full year to show.

Exercise 40.33

Example assignments: "Publish the pilot-light video" → Tony (he is the licensed technician on camera; the safety framing must be his). "NAP cleanup across directories" → the marketing coordinator (execution-heavy, low-judgment, needs consistency — with Marisa approving the canonical NAP). "Approve the Cost Report before publication" → Marisa (data) + Tony (technical accuracy) (Marisa owns the relationship/PR use; Tony verifies the aggregated figures are defensible). Rule of thumb: SME/safety → Tony; relationships/approval/reporting → Marisa; the founding story and the investment decision → Ray; repeatable execution → the coordinator.

Exercise 40.35

The decision line: "We commit to executing this twelve-month strategy, reviewing progress against a frozen baseline on the third of every month and judging it by leading indicators early and booked-job volume late — with no ranking promised, because Google decides rankings and we earn the odds, prove the trend, and adjust." It commits to execute, names the cadence (monthly, against baseline), and refuses to promise a ranking — the three required elements.

Exercise 40.36

A defensible Year-2 addition: a systematic conversion-rate-optimization (CRO) and content-refresh program — testing service-page layouts and calls-to-action, and re-running historical optimization across the now-larger content library. It belongs in Year 2, not Year 1, because it depends on Year-1 outputs: you need meaningful organic traffic and conversion data (which accrue over the first year) before A/B testing is statistically meaningful, and you need a body of published, aged content before "refresh what's decaying" is a real workstream. Doing it in Year 1 would be optimizing pages that don't yet have traffic — premature, and a distraction from the foundation and build the roadmap prioritizes.