Vertical SEO playbooks

Everything in the first seven modules applies here unchanged. What differs by vertical is the unit you optimize, the evidence that proves it, and the failure that shows up once you have more than a handful of pages. This module is four tracks; work the one you are in and skim the rest.

For local and service businesses the unit is one service in one place, and the defining constraint is that the place has to be real. A business can serve a city without having any presence in it, and the moment a page implies otherwise, everything downstream inherits a claim the business cannot support.

The unit is one service in one place, and the place has to be real. Local proof beats a swapped city name every time.

Accuracy across owned properties comes first

Name, address, phone, hours, categories, and service areas have to agree everywhere the business controls: the site, the business profile, and any owned directory listing. This is unglamorous, it takes an afternoon, and it is the highest-return work in the track.

Disagreement is worse than absence. A phone number that differs between the site and the business profile is a signal that neither is reliable, and it costs calls from people who tried the wrong one. Module 7's reputation work applies directly here, starting with the sources you can guarantee.

Service areas need the same honesty. Listing forty surrounding towns because the business would accept work there is the local equivalent of an aspirational market in a research brief, and it produces the exact page problem in the next section.

Location pages need local utility

Module 3 covered the city-swap trap at the format level. In this track it is the defining failure, because the template makes it so cheap: one page, forty cities, an afternoon of find and replace.

Track the market, not the average

Local results vary by where the searcher is standing, so a single tracked position for injury lawyer is close to meaningless. Track by market, and treat each market as its own cohort with its own conversion path.

Conversions matter more here than in almost any other track, because the action is often a phone call. A call is invisible to most analytics setups unless somebody deliberately instruments it, which means the outcome layer of module 1's tree stays empty by default in exactly the vertical where it is easiest to fill.

Work the local track

Four steps. The first is the one people skip because it produces no new pages.

1. Reconcile the business facts across owned properties.Name, address, phone, hours, categories, service areas. Fix what you control before asking a directory to change anything.
2. Build location pages only where local proof exists.Two genuine local specifics minimum. The fortieth city without them belongs on a regional page rather than its own URL.
3. Connect proof and the contact path.Reviews, staff, policies, and a contact action that works on a phone. Local intent is frequently urgent and the path has to be short.
4. Track and measure per market.Separate cohorts per place, and instrument the call. An untracked phone call is the most common missing outcome in this vertical.

Ecommerce is the track where scale turns small mistakes into large ones. A template flaw on an eight-page site is a finding. The same flaw across forty thousand product URLs is a crawl budget problem, an indexing problem, and a reporting problem at once.

The unit here is the category first and the product second. Categories serve the shopping task of narrowing a set, which is where most commercial demand actually sits, and they are usually the pages a store under-invests in while writing product copy nobody reads.

Optimize the category before the product, and decide which generated URLs are allowed to exist before the generator makes that decision for you.

Facets are the defining problem

Filters and sorts generate URLs. Left alone, a store with six filter dimensions produces a combinatorial explosion of addressable pages, almost none of which anybody searches for and all of which compete for the crawl.

The decision is which facet combinations have real demand. Waterproof hiking boots is a search people perform, so that combination deserves an indexable page with its own content. Waterproof hiking boots sorted by price ascending in size nine is not, and it needs to be reachable for a shopper without being indexable for a crawler.

Make that decision explicitly and write it down as a rule. Faceted URL handling that lives only in a developer's memory gets rebuilt differently at the next platform migration, and the problem returns at full scale.

Variants, availability, and the states nobody plans for

Product information has to agree with the merchant feed. When the page says one price and the feed says another, one of them is wrong in a place customers can see, and the discrepancy is usually discovered by a customer rather than by the team.

Transaction information is content, not legal boilerplate. Shipping cost, delivery window, return terms, and who the merchant actually is are decision information. A shopper comparing two stores uses them to choose, and burying them in a linked policy page means losing to the store that answered on the product page.

This is also where structured data earns its place in this track more than in any other, because the properties describe facts a shopper can see: price, availability, and identifiers. Module 5's rule still holds without modification. The markup restates what the page shows, and it inherits every inaccuracy the feed reconciliation above did not catch.

Work the ecommerce track

Five steps, and the second one is the one that prevents the crawl problem rather than remediating it.

1. Map categories to real shopping tasks.How people actually narrow, which is rarely how the catalog is organized internally. Category structure inherited from the warehouse is the usual starting point and rarely the right one.
2. Decide which facet combinations may be indexable.Based on demand evidence from module 2. Write it as a rule that survives the next migration rather than as a one-off configuration.
3. Define the variant and availability states.All four, before they occur. Discontinued handling in particular, because that is where earned value quietly disappears.
4. Reconcile page data with the merchant feed.Price, availability, and identifiers. A mismatch is visible to customers and to any surface consuming the feed.
5. Check crawl coverage against important pages.Module 4's scope discipline matters most here. If generated URLs are consuming the crawl, your category pages are competing with noise you created.

These two models look unrelated and share one defining problem: the thing that earns visibility and the thing that earns money are further apart than in any other track, and connecting them is most of the work.

A publisher earns attention and sells it, so the outcome is a returning reader rather than a transaction. A product or SaaS site earns a trial or a subscription, usually many visits after the one that gets measured. Both fail the same way, by optimizing the visible middle layer and never establishing what it produces.

The measured visit and the paying action are far apart in both models. Connect them explicitly or you are optimizing a proxy.

Publishers: retention is the outcome

A publisher's visibility problem is rarely acquisition and almost always retention. Pages arrive from search, satisfy a question, and never produce a second visit, which makes the traffic real and the business value close to zero.

That changes what to measure and what to build. Returning readers, subscription starts, and engaged time on the pages that lead somewhere are the outcome layer. Sessions are the middle layer, and a publisher reporting only sessions has the same problem as an agency reporting only rankings.

The archive is a liability as well as an asset. Publishing faster than the library can be maintained is the failure that shows up at scale, and module 6's maintenance workflow is not optional here. Every published page is a page somebody has to decide about later.

Product and SaaS: the page types nobody builds

The evidence problem here is specificity. A product page describing how the software helps teams collaborate is indistinguishable from every competitor's page. Original evidence in this model means real workflows, real numbers, and real limitations, including what the product does not do.

Measure the outcome, not the signup

A trial start is not revenue and a free signup is frequently not even a lead. Both models generate an intermediate action that is easy to count and easy to mistake for the outcome, and optimizing for it produces exactly what you asked for: more of a thing that does not pay.

Connect the visibility work to the action the business actually values, and where that connection cannot be measured yet, record it as unavailable in module 1's terms rather than substituting the countable proxy.

Work the publisher or product track

Six steps. The first one decides which of the two sets of advice above applies to you.

1. Name the business model and the paying action.Subscription, trial, purchase, or readership. The rest of the track depends on this and it is frequently assumed rather than stated.
2. Identify the page types your model needs and lacks.Compare against the six above for product and SaaS, or against retention paths for a publisher. The gap is usually obvious once written down.
3. Find the template risk before scaling.Both models publish at volume. A weak template repeated four hundred times is a bigger problem than any single page.
4. Define original evidence and who reviews it.Real workflows and real numbers, with a named subject-matter reviewer. Generic capability copy is what makes these sites interchangeable.
5. Connect visibility to the paying action.Not to the trial start or the session. Where the connection is missing, name the gap rather than substituting the proxy.
6. Put the archive on a maintenance cadence.Module 6's workflow, scoped to the library. Publishing capacity without maintenance capacity is a debt that compounds quietly.

International work fails in a predictable order. A site gets translated, the translations are published under some URL pattern nobody documented, hreflang is added later by a plugin, and six months on the German page is ranking in Austria while the Austrian page ranks nowhere and nobody can say why.

The unit is the language and market pair, and the reason to treat it as a pair is that they vary independently. German for Germany and German for Austria are different targets with different competitors, different legal requirements, and sometimes different products.

The unit is language and market together. Translation is the smallest part of the job and the only part most teams budget for.

Decide the URL structure once, deliberately

Subdirectory, subdomain, or country domain. Each has real trade-offs in operational cost, signal consolidation, and how easy it is to run separately, and the decision is expensive to reverse because it is a migration.

Choose for how the business actually operates. A company with one team serving several markets is better served by subdirectories, which keep everything consolidated and cheap to maintain. A company with genuinely separate country operations, separate legal entities, and separate teams may justify country domains, and will pay for them in duplicated effort.

Whatever you choose, document it before anything is published. The most common international problem is not a wrong structure but three structures coexisting because nobody wrote the first one down.

Localization is not translation

This means module 2's research runs again per market. Using the home market's keyword set in translation is the international version of assuming the intent column was right, and it produces a site that targets terms nobody in that country uses.

hreflang has to be reciprocal and agree with everything else

Annotations must point both ways. If the English page names the German page as an alternate, the German page has to name the English one back, and a one-directional annotation is ignored rather than half-honored.

It also has to agree with the canonical tags, the internal links, and the sitemap. A page annotated as the German alternate while canonicalizing to the English version is sending two contradictory instructions, and the engine will resolve the contradiction in a way nobody chose.

Read performance per market, never in aggregate. A site-wide report across eight countries hides the one market that collapsed, because the other seven cover for it. Segment by country from the beginning, and treat each pair as its own reporting line.

Ownership per market

Every language and market pair needs somebody accountable for it. International programs decay because the pages are published centrally and then owned by nobody, so nothing gets updated when local circumstances change.

That ownership does not have to be a full team. It has to be a named person who checks the market's performance, knows when a local competitor appears, and can say whether the content is still accurate for that country.

Work the international track

Seven steps. The first two are decisions, and reversing either one later is a migration.

1. List the language and market pairs you actually serve.Serve, not aspire to. Each pair is real ongoing cost, and an unstaffed market is worse than an absent one.
2. Choose and document the URL structure.Based on how the business operates rather than on a general recommendation. Write it down so the second market does not invent a different pattern.
3. Run keyword research per market.In the local language, against local competitors. Translating the home market's keyword set is the fastest way to target terms nobody uses.
4. Localize the commercial and legal specifics.Pricing, guarantees, disclosures, and local proof. This is the part translators are not asked to do and cannot do.
5. Implement hreflang reciprocally.Both directions, agreeing with canonicals, internal links, and sitemaps. A contradiction between them is resolved by the engine rather than by you.
6. Segment all reporting by market.From the first day. Aggregate international reporting hides the failing market behind the working ones for as long as it takes to become expensive.
7. Name an owner per pair.Somebody who checks that market and can say whether the content is still true there. Unowned markets decay silently and are usually noticed a year late.