The Dotcom Design SEO Strategy system exists to produce consistent, data-driven, and defensible local SEO strategies for our clients. It replaces a multi-hour manual process prone to subjective decisions with a systematic workflow that ensures every strategy is built on a foundation of clear rules and verifiable data.

The system's primary output is a client-facing, branded website that presents the final keyword-city matrix and demonstrates the rigorous research that produced it. This is not just a deliverable; it is a sales tool that shows the client exactly what they are paying for and why.

Why Rules Matter

Every error that has occurred in past strategies came from one of three root causes: logic gaps (no rule existed to prevent a bad decision), data structure bugs (a rendering assumption was not documented), or pricing from memory (numbers were invented instead of referenced). This Playbook exists to eliminate all three. Every decision point has a documented answer. Adherence is not optional.

The Output

Every completed strategy produces two deliverables: a live, branded strategy website at seo-strategy.dotcomdesign.com/{clientdomain} and a keyword-city matrix that is pasted into the Build Prompt for the website build. The strategy website is shared directly with the client and serves as the documented rationale for every page that will be built.

The Combination Formula

Every plan's combination count is the product of the number of selected keywords and the number of selected markets. The formula is always: Keywords x Markets = Total Combinations. The plan level determines the total, and the keyword/market split is a strategic decision. For example, Plan A (20 combinations) could be 4 keywords x 5 markets, or 2 keywords x 10 markets, depending on the client's service breadth and geographic footprint.

What to Extract

Browse the client's website thoroughly. The goal is to build a complete picture of the business before any keyword research begins. Extract the following: the exact business name as it appears on the site, the industry and business model (showroom, contractor, service provider, etc.), the HQ city and state, a complete list of every service or product category offered, and the defined service area or radius.

Sitemap Check

After reviewing the main site, check the sitemap for existing city or service-area pages. Try these URLs in order: /sitemap.xml, /sitemap_index.xml, and /page-sitemap.xml. Record any existing keyword-city combinations. When building the matrix, these combinations should be noted as existing assets in the market table's rationale column.

Required Inputs Table

The Bucketing Process

For each client service line, identify the primary search term. That term becomes the bucket's name and its base keyword. Every other keyword in that bucket must share that exact core term. Modifiers (near me, custom, store, showroom, companies) are added to the core term to create variants. A modifier alone does not create a new bucket; a different core term does.

Correct vs. Incorrect Examples

The Base Keyword Requirement

Every bucket in the keyword_table data array must have exactly one entry with variant_type: "base". This entry is the rendering anchor for the entire family. If a family only has near-me or modifier variants and no base keyword is explicitly added to the data, the rendering function loses its grouping anchor and will incorrectly nest those rows under the previous family in the table. This has caused repeated visual bugs and must be enforced without exception.

// CORRECT
{ family: "countertops", keyword: "countertops", variant_type: "base", ... },
{ family: "countertops", keyword: "countertops near me", variant_type: "near_me", ... },
{ family: "granite countertops", keyword: "granite countertops", variant_type: "base", ... },
{ family: "granite countertops", keyword: "granite countertops near me", variant_type: "near_me", ... },

// WRONG - missing base keyword for granite countertops family
{ family: "countertops", keyword: "countertops", variant_type: "base", ... },
{ family: "countertops", keyword: "countertops near me", variant_type: "near_me", ... },
{ family: "granite countertops", keyword: "granite countertops near me", variant_type: "near_me", ... },
// ^ This will render "granite countertops near me" nested under the countertops family

Keyword Exclusion Rules

The following keyword types must be excluded from all research output regardless of search volume.

The Market Selection Formula

The number of markets to select is always calculated as: Total Plan Combinations divided by Number of Selected Keywords. This is a hard formula. Once the number is calculated, select the top N markets from the master list in strict descending order by population, always starting with the client's HQ city.

Number of Markets = Total Plan Combinations / Number of Selected Keywords

Examples:
  Plan A (20 combos) with 4 keywords  = 5 markets
  Plan A (20 combos) with 2 keywords  = 10 markets
  Plan B (30 combos) with 5 keywords  = 6 markets
  Plan C (40 combos) with 4 keywords  = 10 markets
  SEO Booster (10 combos) with 1 keyword = 10 markets

Market Tiering Rules

Multi-County Regions

For clients serving a multi-county region (e.g., "Western Pennsylvania" or "the Greater Phoenix Area"), run the market analysis script per county and combine the results. Filter to cities within approximately 35 to 40 miles of the client's HQ. Always include county seat cities in the list even if their population falls below the Tier 1 threshold.

Handling Excluded Markets

When a market is explicitly excluded by the client (e.g., "not Seattle"), remove it from the master list entirely before applying the selection formula. Do not count it as one of the selected markets. Document the exclusion in the market table's rationale column and in the Tier 3 card.

Selection Priority Rules

Keyword selection follows a strict priority order. These rules must be applied in sequence.

Go Wide vs. Go Deep

Once keywords are selected, the combination formula determines how many markets to target. The strategic decision is whether to go wide (fewer keywords, more markets) or go deep (more keywords, fewer markets). Use the following guidance to make this decision.

File Structure

Every client strategy site lives in its own directory named after the client's domain. The directory is created inside the seo-strategy-repo repository.

/home/ubuntu/seo-strategy-repo/
  {clientdomain}/
    index.html      (from references/index_template.html)
    app.js          (from references/app_template.js)
    charts.js       (from references/charts_template.js)
    style.css       (from references/style_reference.css)
    assets/
      logo_primary.png
      logo_reversed.png

Matrix Orientation Rule

The orientation of the keyword-city matrix is determined by the number of selected markets. This rule exists to prevent city column headers from overlapping when there are many markets. It must be applied automatically based on the market count.

The STRATEGY Data Object

The entire strategy is driven by a single JavaScript constant called STRATEGY in app.js. Every section of the website reads from this object. The structure must be followed exactly. Key fields and their requirements are documented in the Data and CSS Rules section.

Assembly Checklist

1. Read dotcom-design-brand skill and all reference files in seo-strategist skill.
2. Create the client directory: mkdir -p /home/ubuntu/seo-strategy-repo/{clientdomain}/
3. Copy style.css and assets/ from an existing client directory.
4. Write app.js using app_template.js as the base. Populate the full STRATEGY object.
5. Write charts.js using charts_template.js as the base. Set selectedCount to the number of selected markets.
6. Write index.html using index_template.html as the base. Update the <base href> tag and all client-specific prose.
7. Preview locally with python3 -m http.server 8090 and verify all sections render correctly.
8. Scroll through every section: Overview, Markets, Keywords, Matrix, Not Used, Opportunities.

Deployment Steps

1. Pull the latest changes: cd /home/ubuntu/seo-strategy-repo && git pull origin main
2. Confirm all client files are in place at seo-strategy-repo/{clientdomain}/
3. Add the new client to the clients array in the root index.html.
4. Add the client to the table in README.md.
5. Stage, commit, and push:

cd /home/ubuntu/seo-strategy-repo
git add {clientdomain}/
git add index.html README.md
git commit -m "feat: Add [Client Name] SEO strategy site"
git push origin main

After pushing, wait approximately 40-60 seconds for Vercel to complete the deployment, then navigate to the live URL to verify. Check the hero, markets table, keyword table, matrix, not-used section, and opportunities cards.

Writing Rules (Non-Negotiable)

app.js Data Field Rules

CSS Subgrid Rules

All card grids in the strategy site use CSS Subgrid for horizontal alignment. This is not optional. The pattern requires two components: the parent grid defines the row tracks, and each card uses grid-template-rows: subgrid to inherit those tracks.

/* Parent grid defines tracks */
.opportunities-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  grid-template-rows: auto auto auto auto auto 1fr minmax(24px, auto) auto; /* 8 tracks */
}

/* Card inherits tracks via subgrid */
.opp-card {
  display: grid;
  grid-row: span 8;
  grid-template-rows: subgrid;
}

/* Mobile fallback - REQUIRED */
@media (max-width: 900px) {
  .opp-card {
    display: flex;
    flex-direction: column;
    grid-row: span 1;
  }
}

The opp-card 8-Child Rule

Every .opp-card must contain exactly 8 child divs in this exact order. If a plan level does not add new markets, the .opp-new-market div must still be rendered with style="visibility:hidden" as a placeholder to maintain subgrid alignment.

<div class="opp-card">
  <div class="opp-plan-label">...</div>          <!-- 1 -->
  <div class="opp-price">...</div>               <!-- 2 -->
  <div class="opp-combos-large">...</div>        <!-- 3 -->
  <div class="opp-combos">...</div>              <!-- 4 -->
  <div class="opp-headline">...</div>            <!-- 5 -->
  <div class="opp-desc">...</div>               <!-- 6 -->
  <div class="opp-new-market">...</div>         <!-- 7: use visibility:hidden if no new market -->
  <div class="opp-kw-list">...</div>            <!-- 8 -->
</div>

Every error documented here has occurred in a real strategy build. Each entry describes what went wrong, why it happened, and the specific rule that prevents it from happening again.

Complete every item on this checklist before delivering a strategy. A strategy is not complete until every box is checked. Click each item to mark it complete.