Topical Authority Map Skill

(Paste-in version: the skill plus its three reference files in one block. Where it says to load a reference file, read that part further down this prompt.)

You are building a Topical Authority Map. This is a structured site architecture built around how we think Google and AI search engines decide which sites are the specialist on a topic. It is NOT a keyword list. It is NOT a list of topics. It is the blueprint for an entire website's content strategy, built around a single central entity and routed through four connected clusters.

The four clusters:

1. **Core Pages** (the money pages users buy from)
2. **AOR Pages** (Areas of Relevance, the supporting authority articles)
3. **Linking Map** (which page links to which page, with what anchor text)
4. **Buyer Journey** (every page tagged TOFU, MOFU, or BOFU)

Plus a fifth output: a 12-week Publishing Order with content briefs that turns the map into a content plan.

**Output:** Two deliverables.

1. `.xlsx` spreadsheet with five tabs: Core Pages, AOR Pages, Linking Map, Buyer Journey, Publishing Order.
2. `.md` strategy document covering central entity, source context, persona, folder structure, linking rules, an optional NLP category check, and quality standards.

**Mode:** Interactive. Pause at the five checkpoints (marked **Checkpoint 1** to **Checkpoint 5** in the reference files) to confirm decisions with the user before proceeding. Do not skip checkpoints.

**Data honesty.** This skill leans on search volumes, SERPs, People Also Ask and autocomplete. Use them only when you can actually see them: through a web search tool, a keyword tool, or data the user pastes (Semrush, Ahrefs, Google Keyword Planner). Search Console impressions are not search volume: they count how often this one site appeared in results, not how many people searched. If the user gives you impressions, keep them in their own column headed "GSC impressions" with the date range, never in the Search Volume column, and never use them for the merge and split thresholds. When you cannot see real volumes, say so, ask the user to paste what they have, and write "no data" in the Search Volume column. Never estimate a search volume or invent a PAA question and present it as researched. Where volume is missing, make merge and split calls on competitor coverage and on whether it is a service the business sells, and say that is what you did.

**No file tools?** If you cannot create files in this environment, output each spreadsheet tab as its own CSV code block and the strategy document as markdown, and tell the user to paste each CSV into a separate sheet.

---

## Why we think topical maps work

Here is how we think about why topical maps work. These five points are our working theory from running this method on client sites, not confirmed Google mechanisms, and none of them is E-E-A-T marketing:

1. **Historical user data accumulation.** Our working theory: every visitor adds to Google's picture of your site, so a topical map concentrates that picture on one topic and gives Google more evidence that you satisfy users on it. Spread it across four unrelated topics and we think you lose on all four.
2. **Knowledge Graph alignment.** Google has entities with attributes and relationships. We think a site built to MATCH what Google already knows about your entity is easier for Google to understand and match to searches.
3. **Lower cost of retrieval.** Every title, heading, paragraph, and image should map to a real query. Our working theory: pages that answer a clear query in a clear structure are easier for Google to understand and rank.
4. **Satisfaction signal transfer.** We think that when an AOR page satisfies a reader and links to a core page, it helps that core page too. More good AOR pages, stronger core pages.
5. **Index construction efficiency.** Our reasoning: it is simpler for a search engine to serve one site for many related queries than many different sites for one query each, so deep, well-organised coverage gives Google a reason to serve more of the topic from your domain.

**Critical warning:** A topical map filled with low-quality content hurts the whole site. Bad pages drag every other page down. Do not publish to fill the map. Every article must be quality work. If you cannot write a good article on a topic, leave it out.

---

## Execution order

Load reference files as you progress through each phase. Complete every checkpoint before moving on.

**Phase 1: Research and classification** (load `references/01-research-and-classify.md`)
- Step 1: Define the central entity (Checkpoint 1)
- Step 2: Source context plus persona, the real author or reviewer (Checkpoint 2)
- Step 3: Deep research on Knowledge Graph, competitors, client situations, attributes (Checkpoint 3)
- Step 4: Classify each attribute as Core or AOR
- Step 5: Merge and split decisions plus depth calibration (Checkpoint 4)

**Phase 2: Architecture and keywords** (load `references/02-architecture-and-keywords.md`)
- Step 6: Define folder structure
- Step 7: Map every page to TOFU, MOFU, or BOFU (Checkpoint 5)
- Step 8: Query expansion plus cost of retrieval scoring
- Step 9: Keyword selection for page titles
- Step 10: Define the linking architecture

**Phase 3: Execution and output** (load `references/03-execution-and-output.md`)
- Step 11: Central entity sitewide presence
- Step 12: NLP category check (optional diagnostic)
- Step 13: Content briefs for the first 30 articles
- Step 14: Publishing order across 12 weeks
- Generate the .xlsx with five tabs
- Generate the strategy .md document

When you finish, present both deliverables to the user with a one-paragraph summary of what to read first (Core, then AOR, then Linking, then Buyer Journey, then Publishing Order) and where to start writing this week.

**The map is dynamic, not static.** Google's indexes change. Review and update the map quarterly.

---

# REFERENCE FILE: references/01-research-and-classify.md

# Phase 1: Research and Classification

This phase produces the foundation. You define the central entity, set source context and persona, do deep research on the topic and the Knowledge Graph, then classify every attribute as Core or AOR with depth calibration.

There are four checkpoints in this phase (Checkpoints 1 to 4). Pause at each one and confirm with the user before proceeding.

---

## STEP 1: DEFINE THE CENTRAL ENTITY

Take the user's seed keyword and define the central entity.

**The central entity is the ONE thing the site is about, expressed as a keyword.**

Ask yourself: "If Google gave this site a Knowledge Panel, what would the title be?"

**Format:** `[service or product] + [location or modifier]` where applicable.
- "family lawyer Sydney"
- "rhinoplasty Denpasar"
- "SEO agency Melbourne"
- "premium Australian furniture"
- "online casino" (no location for digital-only)

**Entity-Attribute-Value (EAV) thinking.** The entity has attributes (things Google knows about it) and values (specific data points). Your topical map must cover all the important attributes.

Example. Entity: Michael Jordan
- Attribute: height. Value: 1.98m
- Attribute: team. Value: Chicago Bulls
- Attribute: spouse. Value: Yvette Prieto
- Each of these is a separate entity in Google's system

Example. Entity: Family Lawyer Sydney
- Attribute: services. Values: divorce, custody, property settlement
- Attribute: jurisdiction. Value: NSW, Family Law Act 1975
- Attribute: qualifications. Value: Law Society accredited specialist

**Checkpoint 1.** Confirm with the user:
- "Is [central entity] correct as your main entity?"
- "Is there a location component?"
- "Any modifier I should add (for example 'affordable', 'specialist', 'emergency', 'premium')?"

Wait for the user to confirm before continuing.

---

## STEP 2: SOURCE CONTEXT AND PERSONA

Before picking any topics, define WHAT the site is and WHO is behind it. Both change the entire map.

### 2A: Source Context

Ask the user these five questions:

1. **Business type.** Service provider, retailer, manufacturer, affiliate, media, SaaS, marketplace, or other?
2. **Location and market.** Local (single city), regional, national, or international? Note the state or jurisdiction. Laws and regulations may be state-specific.
3. **Unique angle.** What makes this business different from competitors? (Cheapest, fastest, most experienced, only one doing X, etc.)
4. **Customer language.** How do customers describe this business? (Not how the business describes itself.)
5. **Knowledge Panel test.** If Google created a Knowledge Panel for this business, what would the two-sentence description say?

**Why source context matters.**
- A casino AFFILIATE needs comparison content, bonus pages, review pages.
- A casino OPERATOR needs game pages, responsible gambling, licensing pages.
- A casino TECH PROVIDER needs integration docs, API pages, case studies.
- Same niche, completely different maps.
- Source context determines which attributes matter most and how content is framed.

### 2B: The Persona: a Real Author or Reviewer

Google's guidance asks whether it is clear who wrote your content, with bylines that lead to more about the author. So the persona is always a real person: the person who will write or expertly review the content, with credentials that can be checked. Never invent one.

**Research process.**
1. Look at competitor About pages. What qualifications, job titles, and credentials do they list?
2. Ask the user who will write or review the content. Record that real person's name, job title, qualifications, professional memberships, and career summary, and ask how each credential can be checked (a public register, a membership directory, a licence number, a professional profile). Leave out anything that cannot be checked.
3. If nobody on the team has the expertise for a topic, say so and recommend a real, qualified reviewer. Never make up a person, a name, or a credential, and never suggest publishing under an invented byline.
4. This persona determines what topics you can credibly cover.

**Example. Family Law.** (An illustrative example, not an author to publish. In a real run, use the actual author's or reviewer's details, and never publish an example persona as a real author.)
- Name: John Bale
- Title: Senior Associate, Family Law
- Qualifications: Law Society accredited specialist, qualified mediator
- Memberships: Law Society of New South Wales

**Why this matters.** If your topical map calls for an article on "battery chemistry" but your site sells electric scooters, you do not need 100 articles on chemistry. You need one or two to show Google you have knowledge of that adjacent topic. The persona keeps you grounded in what is credible.

**Checkpoint 2.** Confirm source context and the persona (the real author or reviewer, with checkable credentials) with the user before proceeding.

---

## STEP 3: DEEP RESEARCH ON THE TOPIC

You cannot build a good topical map without deeply understanding the topic first. Keyword research alone is not enough. You need to understand the relationships between entities.

### 3A: Knowledge Graph Research

Use these tools to map the entity's Knowledge Graph neighbourhood:

1. **Wikipedia.** Search for the entity type. Section headings are attributes. Related articles are adjacent entities. "See also" is closely related topics.
2. **Wikipedia Graph visualiser** (blinpete.github.io/wiki-graph). Visualise connected topics. Note DISTANCE. Topics close together are strongly related, distant ones are weakly related.
3. **Wikidata.** Structured entity data with explicit relationships.
4. **DBpedia** (dbpedia.org). Knowledge base derived from Wikipedia.

**Key concept: topic distance in vector space.**

Google thinks about topics like GPS coordinates. Topics close together can be connected naturally. Topics far apart cannot.

- Car accidents and car maintenance are CLOSE (a sentence connecting them makes sense: "poor car maintenance has led to the car accident").
- Car accidents and racing helmets are TOO FAR (even though "car" appears in both).
- Drinking water and luxury water are CLOSE.
- Drinking water and faecal coliform are FAR (probably do not need a whole page on it for a water brand).

**Your job.** Decide which connected topics are close enough to your central entity to warrant coverage, and how much coverage (own page vs paragraph vs skip entirely).

**Node importance. How to judge what deserves more coverage.**
- **Degree.** How many connections does this topic have? More connections, more important, more coverage.
- **Eigenvector centrality.** Is it connected to OTHER important nodes? (Scottie Pippen matters more than Jordan's dad because Pippen is independently significant.)
- **Betweenness.** Must you pass through this topic to reach other topics? (To talk about water and human health, you must go through drinking water.)
- **Closeness.** How close is it to other important topics in your niche?

The size of a topic on your website should roughly match its importance in the Knowledge Graph.

### 3B: Competitor Research

1. **Extract competitor sitemaps.** Find three to five competitors and grab their sitemaps and site structures.
2. **Analyse their folder structures.** What topics do they cover? What is their hierarchy?
3. **Note gaps.** What topics are they missing? (These are your information gain opportunities.)
4. **Note thin content.** Competitors with 50-word pages on important topics are easy to beat.
5. **Research their About pages.** What personas and credentials do they use?

### 3C: Client and Customer Situation Mapping

For service businesses, map out the specific SITUATIONS your clients find themselves in. This is critical because:
- Each situation creates a unique content angle.
- Each situation determines which internal links make sense.
- You do not link to child custody content from an article about unmarried couples with no kids.

**Example. Family Law.**

| Persona | Situation | Services Needed | Related Topics |
|---|---|---|---|
| Father | Wants full custody of son | Child custody, parenting plans | Visitation rights, father's rights |
| Mother | Separating, cannot support herself | Spousal maintenance, property settlement | Financial agreements, Centrelink |
| Grandparent | Wants to see grandchildren | Visitation hours, grandparent rights | Custody arrangements |
| Unmarried couple | De facto relationship ending, no kids | Property settlement, de facto law | Section 4AA Family Law Act |
| Married couple | Divorcing with significant assets | Divorce, property settlement | Consent orders, binding financial agreements |

Each situation drives content creation AND internal linking decisions.

### 3D: Find Every Attribute of the Entity

Research ALL attributes using these sources. Do them all. No shortcuts.

If your tools do not show you live results, People Also Ask boxes or autocomplete suggestions, say which sources you could not reach and ask the user to paste them. Never fill a source with questions or suggestions you made up.

#### Source 1: Top 5 Google Results
- Web search: `[central entity]`
- Open the top 5 organic results.
- List every SERVICE, FEATURE, PRODUCT, or SUB-TOPIC mentioned on each page.
- Note which attributes appear on three or more of the five pages. Those are mandatory.

#### Source 2: People Also Ask
- Web search: `[central entity]`
- Capture every PAA question visible.
- Each PAA reveals an attribute users care about.
- Click into two or three PAAs to reveal nested PAAs and capture those too.

#### Source 3: Wikipedia
- Section headings on the Wikipedia page are entity attributes.
- Related articles linked from the Wikipedia page are adjacent entities (potential AOR topics).
- The "See also" section is closely related topics.
- For law, finance, medical, or other regulated industries, note the specific legislation (for example Family Law Act 1975 for Australian family law).

#### Source 4: Keyword Tools and Google Autocomplete
- Web search: `[central entity] a`, `[central entity] b`, `[central entity] c`, through the alphabet.
- Each autocomplete suggestion is a potential attribute.
- Also search: `[central entity] for`, `[central entity] vs`, `[central entity] how`, `[central entity] cost`, `[central entity] best`.
- Group results by intent type (informational, commercial, navigational).

#### Source 5: Business Service or Product List
- Ask the user: "List every service, product, or offering this business provides."
- Each one is a mandatory core attribute regardless of search volume.

#### Source 6: Relevant Laws, Regulations, Standards
- For regulated industries, identify the specific legislation, regulations, or industry standards.
- These MUST be part of your topical map. You cannot discuss the topic without referencing them.
- Example: Family Law Act 1975, Section 4AA (de facto relationships), Part VII (children).

**Compile the master attribute list.** Format:

| # | Attribute | Source(s) Found | Intent Type | KG Distance | Notes |
|---|---|---|---|---|---|
| 1 | Cost or pricing | Google results, PAA, autocomplete | Commercial | Close | All 5 competitors have this |
| 2 | Recovery timeline | Wikipedia, PAA | Informational | Close | Strong AOR candidate |
| 3 | Battery chemistry | Wikipedia (adjacent) | Informational | Medium-far | 1-2 articles max, not core topic |

**Checkpoint 3.** Present the full attribute list AND client situation map to the user. Ask: "Are there any attributes missing? Any services I have not captured? Any client situations I am missing?"

---

## STEP 4: CLASSIFY EACH ATTRIBUTE AS CORE OR AOR

Split every attribute into one of two buckets.

### Core Pages (the money pages)
- Commercial or transactional intent.
- Pages that convert visitors into customers or leads.
- Service pages, product pages, pricing pages, booking pages, landing pages.
- Keywords contain: "buy", "hire", "cost", "near me", "best", "[service] + [location]", "[product] review".

### AOR Pages (Areas of Relevance)
- Informational intent.
- Pages that build authority and funnel it to core.
- Guides, how-tos, explainers, listicles, comparisons, history, tips.
- Keywords contain: "how to", "what is", "guide to", "tips for", "history of", "vs", "types of", "examples of".

For each attribute, tag it:

| Attribute | Classification | Reasoning |
|---|---|---|
| Rhinoplasty cost | CORE | Commercial intent, users are price-shopping |
| Recovery timeline | AOR | Informational, supports the core pages |
| Before and after | AOR | Educational, but could be CORE if it has a gallery and CTA |

---

## STEP 5: MERGE AND SPLIT DECISIONS PLUS DEPTH CALIBRATION

For each attribute, decide if it gets its own page or merges into another page. Then calibrate the DEPTH of coverage.

### The exact thresholds

Volumes must come from a keyword tool or keyword data the user supplies. Search Console impressions do not count: they measure this site's appearances, not searches. If there is none, mark the volume "no data" and decide on the competitor check and the two overrides alone.

| Search Volume (monthly) | Decision | Condition |
|---|---|---|
| 100+ | **Own page** | Enough demand to justify a dedicated page |
| 10 to 99 | **Check competitors** | If 2+ competitors have dedicated pages, own page. If only one or none do, merge |
| Under 10 | **Merge** | Add as a section or paragraph on a related page |
| Any volume | **Own page (override)** | If it is a core service you actively sell, own page regardless |
| Any volume | **Own page (adjacent depth exception)** | An adjacent topic of Medium or High Knowledge Graph importance that the persona expects a specialist to cover. Cap it at 1-2 articles and say why in the Depth column |

### How to check competitor pages
- Web search: `[attribute] + [location or modifier]`
- Check if the top 5 results have DEDICATED pages for this attribute.
- A dedicated page means the URL slug contains the attribute AND the page is mainly about it and covers it properly in its own right. Word count is only a cue to look closer, not a test.
- A mention on a broader page does NOT count as a dedicated page.

### Depth calibration. How much coverage?

The page vs paragraph vs sentence decision:

If you cover something as a WHOLE PAGE (it becomes the title), you are signalling to Google this is a very important topic directly connected to your central entity.

If you cover it as a PARAGRAPH within a page, you are signalling it is related but secondary.

If you cover it as a SENTENCE, it is tangentially relevant.

**Match depth to Knowledge Graph importance.**
- High-degree node (many connections, high search volume): own page or multiple pages.
- Medium node: own page with moderate depth.
- Low node (few connections, but still relevant): paragraph within a related page.
- Very distant node: one sentence or skip entirely.

**Example. Electric Scooter Site.**
- Battery life: OWN PAGE (core attribute, high search volume).
- Battery chemistry: 1-2 ARTICLES (adjacent topic, proves knowledge, but do not write 100 articles).
- Lithium mining: ONE PARAGRAPH in battery chemistry page (too distant).

**Example. Dental Implants.**
- Dental implants: CORE (hub page).
- Bone grafting: OWN PAGE (important sub-topic).
- Bone grafting materials: OWN PAGE (deeper depth, if competitors cover it).
- Human bone vs animal bone: SECTION within bone grafting materials (too narrow for own page).

**Format the decisions:**

| Attribute | Volume | Competitors w/ Page | KG Importance | Decision | If Merge, Into Which Page | Depth |
|---|---|---|---|---|---|---|
| Child custody | 320/mo | 4 of 5 | High | OWN PAGE | n/a | Full depth |
| Relocation disputes | 10/mo | 0 of 5 | Low | MERGE | Child custody page | H2 section |
| Battery chemistry | 20/mo | 0 of 5 | Medium | OWN PAGE (adjacent depth exception) | n/a | 1-2 articles only, to prove knowledge of an adjacent topic |

**Checkpoint 4.** Present merge and split decisions to the user. Ask: "Do these split and merge decisions look right? Any pages you definitely want separate regardless of volume?"

---

End of Phase 1. Once Checkpoint 4 is confirmed, load `references/02-architecture-and-keywords.md` and continue with Phase 2.

---

# REFERENCE FILE: references/02-architecture-and-keywords.md

# Phase 2: Architecture and Keywords

This phase turns the classified attribute list from Phase 1 into a working site architecture: folders, buyer journey tags (TOFU, MOFU, BOFU), expanded queries with cost-of-retrieval scoring, target keywords, and the linking architecture that makes the four clusters compound.

There is one checkpoint in this phase. Pause and confirm before proceeding.

---

## STEP 6: DEFINE FOLDER STRUCTURE

Folders keep the site organised; internal links do the heavy lifting. Google says it mostly works out a site's structure from the links between pages, not from its URLs, so treat folders as a way to keep content organised, and rely on crawlable navigation and internal links to show how pages relate.

### Recommendations
1. Each major topic gets its own folder.
2. Folder name is the ROOT KEYWORD ONLY (just "divorce", not "divorce-lawyer-sydney").
3. Use Semrush Keyword Magic (or equivalent): type the root word, check all variations, pick the right root. If neither you nor the user has a keyword tool, pick the root from the language competitors and the user's customers use, and say it is unchecked.
4. Sub-topics live inside the parent folder.

### Example. Family Law.

```
/family-lawyer-sydney/          (Core hub page)
/family-law/
  /divorce/
    /divorce-application/
    /divorce-process/
    /property-settlement/
  /custody/
    /child-custody/
    /parenting-plans/
    /visitation-rights/
  /de-facto/
    /de-facto-relationships/
    /property-settlement-de-facto/
  /family-law-act/
    /section-4aa/
    /part-vii-children/
```

### Why we use folders
- Forces you to think about which category each page belongs to.
- Keeps related pages together (all `/divorce/` pages sit side by side), which makes the internal linking easier to plan.
- Easier to report on in analytics.
- Easier for people to follow. On larger sites (more than a few thousand URLs), folders can also help Google learn how often each section changes. Use internal links to show how pages relate.
- In WordPress, use Pages (not Posts) with parent and child relationships to build this structure.

### Image URLs follow folder structure
- Images embedded on pages should have URLs that include relevant keywords.
- Example: `/family-lawyer-sydney/john-bale-family-lawyer.jpg`
- Image alt tag varies by context. On profile page: "John Bale Family Law Associate". On Sydney family lawyer page: "John Bale Family Lawyer Sydney".

---

## STEP 7: MAP EVERY PAGE TO TOFU, MOFU, OR BOFU

Every page must sit in one of three buyer journey stages. (For more nuance you can split BOFU into Decision and Retention. For a public map, keep it to three.)

### TOFU. Top of Funnel
- User has a PROBLEM but is researching, not buying.
- Content type: problem-awareness, definitions, explainers, "what is" articles.
- Keyword patterns: symptom-based, question-based, problem-description, "what is", "how does", "why does".
- Examples: "my tooth hurts", "water leaking from ceiling", "what is property settlement".
- Page role: educate about the problem, introduce the solution category, link to MOFU pages.
- This is most of your AOR content.

### MOFU. Middle of Funnel
- User knows the solution exists, evaluating WHETHER and HOW to act.
- Content type: comparison content, "how to choose", buyer guides, "X vs Y" articles, pricing explainers, case studies.
- Keyword patterns: "best [service]", "how does [service] work", "[A] vs [B]", "[service] cost", "[service] near me".
- Examples: "rhinoplasty surgeon Denpasar", "emergency plumber near me", "how to choose a dining table".
- Page role: move researchers into decision mode. This is where most websites have the biggest gap.

### BOFU. Bottom of Funnel
- User is ready to act and choosing WHO.
- Content type: service pages, product pages, pricing pages, booking pages, testimonials, brand reviews.
- Keyword patterns: "[brand] reviews", "[service] [location]", "[service] pricing", "buy [product]", "book [service]".
- Examples: "rhinoplasty Bali clinic", "Dr Smith reviews", "buy Australian oak dining table".
- Page role: convert. These are your money pages.

### Optional: Retention layer
For service businesses with repeat customers (medical, legal, home services), add a fourth layer for after-service content (aftercare guides, maintenance, FAQ, support). It builds authority, drives return traffic, and generates reviews and referrals.

**Format:**

| Page | Stage | Content Type | Target Keyword |
|---|---|---|---|
| Rhinoplasty Services | BOFU | Service page | rhinoplasty denpasar |
| How to choose a dining table | MOFU | Buyer guide | how to choose a dining table |
| What is European oak | TOFU | Definition | what is european oak |
| Dr Smith vs Competitors | MOFU | Comparison | best rhinoplasty surgeon bali |
| Recovery Timeline | Retention | Aftercare guide | rhinoplasty recovery |

**Gap check.** If any stage has zero pages, flag it. Ask the user: "You have no [TOFU / MOFU / BOFU] stage content. Should we add pages for this stage?" The most common gap by far is MOFU. That is where most of the conversion work happens, and where most websites are weakest.

**Checkpoint 5.** Present the buyer journey mapping. Flag any gaps and propose new pages to fill them.

---

## STEP 8: QUERY EXPANSION AND COST OF RETRIEVAL

For each page, identify ALL the sub-queries Google would expand the target keyword into. Then score the page's cost of retrieval.

### How to find expanded queries

1. **Web search:** `[target keyword]`. Capture PAA questions.
2. **Think through the seven query types.** For each page's keyword, ask:
   - What is [keyword]? (Definition.)
   - How to [keyword]? (Instruction.)
   - [keyword] vs [alternative]? (Comparison.)
   - Why [keyword]? (Reason.)
   - [keyword] cost or price? (Short fact.)
   - Is [keyword] worth it? (Boolean.)
   - What happens if [keyword]? (Consequence.)
3. **Check competitor headings.** What H2s do the top 5 results use? Each H2 is a sub-query they are targeting.

### Decide. Page or section?

For each expanded query:
- If competitors have DEDICATED PAGES, it needs its own page (add to map).
- If competitors cover it as an H2 or section, cover it as an H2 on your page.
- If no competitors cover it, that is potential information gain (cover it as an H2).

### Cost of retrieval score

For each page, give it an editorial score out of 10. This is our own heuristic, not a measure of anything Google calculates: "How clearly does this page answer its target queries?"

A 10 of 10 page:
- Every heading maps to an actual search query.
- Every paragraph answers a potential question.
- Every image could rank in image search for a related query.
- The title, H1, URL, and meta description all reinforce the same keyword.
- A clear, short answer could be lifted straight out as a featured snippet.

A 1 of 10 page:
- Generic headings ("Our Services", "About").
- No clear keyword targeting.
- Content that does not answer any specific query.
- It is hard to tell what the page is about.

**Format:**

| Page | Expanded Query | Competitors: Page or Section? | Decision | CoR Score |
|---|---|---|---|---|
| Rhinoplasty Cost | how much does rhinoplasty cost in bali | 3 of 5 have dedicated page | OWN PAGE (already in map) | 8/10 |
| Rhinoplasty Cost | is rhinoplasty covered by insurance | 0 of 5 have page, 2 of 5 have H2 | H2 SECTION | n/a |
| Rhinoplasty Cost | rhinoplasty financing options | 0 of 5 cover this at all | H2 SECTION (info gain) | n/a |

**Passage ranking note.** Google can find answers DEEP in your article. A concise answer to "how long does the divorce process take" buried as a paragraph in your divorce article can rank for that specific query via passage ranking. Every paragraph should answer a potential question concisely.

**If this step generates NEW pages not already in the map, add them and re-run Steps 4 and 5 for the new pages.**

---

## STEP 9: KEYWORD SELECTION FOR PAGE TITLES

For each page in the map, select the exact target keyword using this process.

### Step 9A: Find the root word
- Go to Semrush Keyword Magic (or equivalent) and type the ROOT of the keyword.
- For "divorce", type just "divorce".
- For "car accident lawyer", type "car accident" or "car accident lawyer".
- The root word lets you see all variations and pick the right one.

### Step 9B: Pick the page title keyword
- Look at search volume for all variations.
- Pick the variation that matches your SOURCE CONTEXT.
- "Divorce application" (transactional, user intent is apply for divorce). Use if you help people apply.
- "Royal divorce" (news topic, too distant) unless you are specifically a royal family law specialist.
- "Divorce rate" could work for an AOR article with statistics.

### Step 9C: Keyword selection strategy. The mix.

You need a MIX of:

**One or two high-competition, high-volume keywords per topic folder.**
- These establish your authority on the broad topic.
- You will rank lower at first, but we think they help show Google you are in this space.
- Examples: "divorce" (4,000/mo), "child custody" (2,000/mo). (Illustrative figures. Use real volumes from a keyword tool, never estimates.)

**Several easy-to-rank, lower-volume keywords.**
- These get you actual clicks and user data quickly (Avalanche Theory).
- Look for keywords where competitors are ranking BY ACCIDENT (poor page, no SEO).
- Examples: "divorce application QLD" (200/mo, weak competition). (Illustrative.)

**The Avalanche Theory. Publishing order.** (Our working theory, not a confirmed Google mechanism.)
1. Publish easy-to-rank articles FIRST.
2. Get clicks and start building a track record on the topic.
3. We think that track record builds trust over time.
4. THEN tackle competitive keywords.
5. Our working theory: the trust earned from easy wins helps the hard keywords rank.

### Step 9D: SERP analysis per keyword

For each keyword, check the SERP:
- Are competitors ranking by accident (thin pages, no optimisation)? EASY WIN.
- Are there mostly government or authority sites? HARDER but possible with better content.
- Is the whole first page news sites? SKIP unless you are a news publisher.
- Are competitors using the SAME keyword in their title and URL? DIRECT competition, need strong content.

---

## STEP 10: DEFINE THE LINKING ARCHITECTURE

This is the cluster most websites get wrong, even when the rest of the map is solid.

### The Authority Flow Model

```
[AOR Page A] -----> [Core Page 1] <----- [AOR Page B]
     |                                         |
     v                                         v
[AOR Page C] <----------------------------     |
                                               v
                                          [Core Page 2]
```

The arrows show the main direction. Core pages link back to AOR pages wherever it helps the reader.

### Linking rules. Use these as your default.

| Link Direction | Rule | Reason |
|---|---|---|
| AOR to Core | MANDATORY. Every AOR page links to one or two relevant core pages in body content (nav or footer alone does not count). | Takes readers who are ready to act to the page that serves them, and shows which money page the supporting content backs up. |
| AOR to AOR | ENCOURAGED. Link freely between related AOR pages. | Builds topical cluster depth. |
| Core to AOR | ENCOURAGED. Link from core pages to supporting pages wherever it helps the reader (for example a service page linking to its buying guide or FAQ). | Helps readers who need more before they buy, and keeps the cluster connected both ways. |
| Homepage to Core | MANDATORY. Direct links to most important core pages. | Makes the most important pages easy to reach. Google treats pages with more internal links as more important. |
| Homepage to AOR | OPTIONAL. | Less important than homepage to core. |

### Anchor text guidance
- **Descriptive anchors.** The anchor should tell the reader what the target page is about.
- **A natural mix.** Across the links pointing at a page, a mix works well: some exact-match keyword anchors, some partial matches, some branded or natural-language variations. This is a default, not a fixed sequence, and the same exact-match anchor on every link reads as forced.
- **Never** use "click here", "read more", or naked URLs.
- **Place links** within contextual sentences where the surrounding text reinforces the target page's topic.

### Link placement
- We think body content links carry more weight than nav, sidebar, or footer links.
- Editorial links inside article copy should sit in a contextual paragraph, not a list of links dumped at the bottom. Keep useful crawlable navigation, breadcrumbs and category or related-page lists as well: Google uses links from menus to categories to products to find pages and understand the structure.
- Surrounding text matters. The paragraph around the link should use language relevant to the TARGET page.

### Client-situation-based linking

Internal links must be RELEVANT TO THE READER of the current page.
- An article about "unmarried couple separating, no kids" should NOT link to child custody.
- An article about "father's rights in custody" SHOULD link to parenting plans and visitation.
- Think: "Would the reader of THIS page actually want to read THAT page?" If no, do not link.
- Related-post widgets and automated "related posts" often link to irrelevant pages. This hurts more than it helps.

**Build the linking map:**

| Source Page | Target Page | Anchor Text | Placement | Link Type | Reader Relevance Check |
|---|---|---|---|---|---|
| Recovery Timeline (AOR) | Rhinoplasty Services (Core) | rhinoplasty in Denpasar | Supplementary section | AOR to Core | Yes. Reader is researching rhinoplasty. |
| Father's Rights (AOR) | Child Custody (Core) | child custody arrangements | Body paragraph | AOR to Core | Yes. Father wants custody info. |
| De Facto No Kids (AOR) | Child Custody (Core) | n/a | DO NOT LINK | n/a | No. Reader has no kids. |

---

End of Phase 2. Once you have the folder structure, buyer journey mapping (Checkpoint 5 confirmed), expanded queries, target keywords, and linking map, load `references/03-execution-and-output.md` and continue with Phase 3.

---

# REFERENCE FILE: references/03-execution-and-output.md

# Phase 3: Execution and Output

This phase finishes the map. You define how the central entity appears on every page, optionally check NLP categories, build content briefs for the first 30 articles, sequence the publishing order across 12 weeks, then generate the .xlsx (five tabs) and the strategy .md.

There are no checkpoints in this phase. The map should be complete and confirmed by the time you arrive here.

---

## STEP 11: CENTRAL ENTITY SITEWIDE PRESENCE

Define exactly how the central entity appears on EVERY page.

### Template for every page

1. **Header or nav (template-level):** business name plus what you do.
   - Example: "Dr. Smith. Rhinoplasty Surgeon, Denpasar."

2. **Footer (template-level):** two or three sentence company description that includes the central entity.
   - Example: "Dr. Smith is Denpasar's leading rhinoplasty surgeon, helping patients achieve natural-looking results through advanced surgical techniques."

3. **Every page's intro paragraph:** ONE natural mention of the central entity.
   - Example on AOR page: "At [Clinic Name], our rhinoplasty surgeons in Denpasar recommend the following recovery timeline."

4. **Every page's supplementary section (above footer):** ONE natural mention plus CTA.
   - Example: "If you are considering rhinoplasty in Denpasar, our board-certified surgeons can walk you through the full recovery process during your free consultation."

5. **Every page:** ONE internal link to the main core page.
   - Example: "Learn more about our [rhinoplasty services in Denpasar](/rhinoplasty-denpasar/)."

### Central search intent. Consistent language sitewide.

- Consistent verbs: "provide", "offer", "specialise in".
- Consistent nouns: your services, products, entity names.
- Consistent adjectives: "expert", "experienced", "affordable", "premium".
- These appear in title tags, H1s, heading structure, paragraphs, and image alt text.
- Our working theory: a paragraph that drifts off topic weakens that section, the section weakens the page, and a weaker page is a weaker page to link from. Keep the context consistent.

### What NOT to do
- Do not force the entity into every paragraph. That is keyword stuffing.
- Do not write unnatural sentences to cram it in.
- ONE intro mention, ONE supplementary mention, ONE internal link is enough.

---

## STEP 12: NLP CATEGORY CHECK (OPTIONAL DIAGNOSTIC)

This step is optional. It is a diagnostic for spotting pages that drift off topic, with no pass or fail. Google Cloud's Natural Language API is a separate Google Cloud product: it is not a Google Search ranking test, and no documented Google Search rule says pages must share a category.

### How to check
- Use Google Cloud's Natural Language API (the classifyText method), or manually assess: "What category would this page fall into?"
- Most pages on a focused site should land in the site's main category. A family law site would expect `/Law & Government/Legal` for most pages. Use the API's own category names, which use "&".
- The narrower `/Law & Government/Legal/Family Law` is a V2 category. The API uses the older V1 categories unless you ask for V2, so to get it, add `"classificationModelOptions": {"v2Model": {"contentCategoriesVersion": "V2"}}` to the request.
- A page can legitimately get a different category, or several. A family law page that comes back as `/Health` or `/Shopping` is worth a look, not an automatic rewrite.

### If a page drifts
Look at why first. If it has wandered off topic:
- Rewrite the intro and headings to use language consistent with the site's topic.
- Add the central entity mention (Step 11) to anchor it.
- Check that internal links FROM this page use anchor text relevant to the site's main topic.

If the page is on topic and simply serves a different need, leave it. Note any pages that drift, and what you found, in the strategy document.

---

## STEP 13: CONTENT BRIEFS FOR THE FIRST 30 ARTICLES

A topical map without content briefs is incomplete. You do NOT need briefs for all 90 articles before you can start. Generate briefs for the first 30 (the AOR wave that publishes in weeks 1 to 6) so the user can hand them to a writer immediately.

For the remaining 60, list page title, target keyword, URL slug, and one-line scope. The user can ask for full briefs in a second pass.

### Content Brief Format (first 30)

| Field | Value |
|---|---|
| Page Title | The page title |
| Target Keyword | The target keyword |
| URL Slug | The URL slug (`/folder/keyword/`) |
| H1 | H1 text |
| Title Tag | Title tag, keyword in first five words, 50 to 60 chars |
| Meta Description | 150 to 160 chars, keyword, CTA |
| Buyer Stage | TOFU, MOFU, or BOFU (plus Retention if applicable) |
| Word Count Target | A rough range from competitor analysis. A guide, not a rule: cover what the reader needs |
| H2 Sections | List of H2s, each mapping to an expanded query |
| Internal Links Out | Which pages to link TO, with anchor text |
| Internal Links In | Which pages should link TO this page |
| Entities to Mention | Key entities from Knowledge Graph research |
| Information Gain Angles | What competitors do NOT cover |
| Image Requirements | Number of images, alt tag keywords |
| CTA | What action should the reader take? |
| Persona Angle | How does the real author's or reviewer's expertise frame this content? |
| Client Situation | Which client situation(s) does this page serve? |

### Brief format for articles 31 to 90 (lighter)

| Field | Value |
|---|---|
| Page Title | The title |
| Target Keyword | The keyword |
| URL Slug | `/folder/keyword/` |
| Buyer Stage | TOFU, MOFU, or BOFU |
| One-line scope | What this article must cover |
| Links to (Core) | Which core page it links to |

These can be expanded to full briefs in a follow-up pass once the first wave is shipping.

---

## STEP 14: PUBLISHING ORDER ACROSS 12 WEEKS (AVALANCHE THEORY)

Publish in sequence, not all at once. The plan spreads 90 articles across 12 weeks, but timing varies by site: set the pace by what the team can write well, and adjust as results come in. Here is the order.

### Phase 1: Foundation (week 0, before week 1)
Before the 12-week clock starts, the user should already have:
- Homepage live with central entity mentions (Step 11) wired in.
- Core service or product pages live (the BOFU money pages).
- About page with the real author's or reviewer's details.
- Contact page.

If any of these are missing, week 1 starts here. The 12-week schedule below assumes they exist.

Fix anything broken on the core pages straight away, whatever the week: wrong intent, thin content, pages that are not indexed. Do not save those fixes for later. Only the big core-page rewrites wait for Phase 4.

### Phase 2: AOR Wave (weeks 1 to 6, 30 articles)
- 30 AOR articles targeting low-to-medium competition keywords.
- Five articles per week. Hand the first 30 content briefs straight to a writer.
- Each article links to one or two relevant core pages in the body content.
- Our working theory: these build a track record on the topic before the big core-page rewrites.

We think this is the wave that shows Google you specialise in the topic.

### Phase 3: MOFU Wave (weeks 7 to 10, 40 articles)
- Buyer guides ("how to choose between X and Y").
- Comparisons ("X vs Y").
- Decision-stage content (case studies, brand reviews, pricing explainers).
- 10 articles per week.
- These convert TOFU researchers into BOFU buyers.

In our experience this is the wave most websites skip, and the one that produces most of the conversion lift.

### Phase 4: Core Optimisation (weeks 11 to 12, 20 articles)
- Do the big rewrites of the existing BOFU core pages now that the supporting content is live, so they can link to it and build on it. (Anything broken was fixed in the Foundation phase.)
- Add new BOFU pages where the map has gaps.
- Add a Retention layer if relevant (aftercare, maintenance, FAQ).
- Our working theory: the supporting content from Phases 2 and 3 helps the core pages compete for the high-competition keywords.

### Publishing frequency

Five to ten articles per week suits most teams, but set the pace by what you can publish at a consistently high standard, and adjust it as results come in. Do not rush out a batch of weak articles to hit a number.

### The order, in one sentence

Fix anything broken on the core pages now. Then AOR first, linking woven in throughout, MOFU buyer guides next, and the big core-page rewrites last. How fast results follow varies by site: Google says some changes show within days and others take several months.

---

# OUTPUT GENERATION

## Deliverable 1: spreadsheet (.xlsx) with five tabs

Generate using the xlsx skill. If you cannot create files in this environment, output each tab as its own CSV code block instead, and say so.

### Tab 1: Core Pages

| Page Title | URL Slug | Folder | Target Keyword | Search Volume | Buyer Stage | H1 | Title Tag | Meta Description | Competition Level |

12 to 20 rows. Search Volume holds a real figure from a keyword tool or the user's keyword data, or "no data". Never an estimate, and never Search Console impressions: if the user supplied those, add them as an extra column headed "GSC impressions (date range)". These are the BOFU money pages.

### Tab 2: AOR Pages

| Page Title | URL Slug | Folder | Target Keyword | Search Volume | Buyer Stage | Links To (Core) | H1 | Title Tag | Meta Description | Competition Level |

60 to 80 rows. These are the supporting authority articles.

### Tab 3: Linking Map

| Source Page | Target Page | Anchor Text | Link Type | Placement | Reader Relevance |

Every internal link, with anchor text, link type (AOR to Core, AOR to AOR, etc.), and a reader-relevance check.

### Tab 4: Buyer Journey

| Page | Stage | Content Type | Target Keyword | Notes |

Every page tagged TOFU, MOFU, or BOFU (plus Retention if used). Use cell colour to make the three tiers instantly readable: light yellow for TOFU, light blue for MOFU, light green for BOFU. Retention can be light grey.

### Tab 5: Publishing Order

| Week | # | Page Title | Cluster | Target Keyword | Buyer Stage | Brief Link | Notes |

90 rows. Sequenced AOR Wave (weeks 1 to 6), MOFU Wave (weeks 7 to 10), Core Optimisation (weeks 11 to 12). List any urgent core-page fixes (wrong intent, thin content, not indexed) above them as week 0. Briefs for rows 1 to 30 should be linked or expanded inline. Rows 31 to 90 use the lighter brief format.

## Deliverable 2: strategy document (.md)

Generate a markdown file containing:

1. **Central Entity Definition.** What it is, location, modifier, EAV attributes.
2. **Source Context and Persona.** Business type, market, angle, customer language, and the real author or reviewer with their checkable credentials.
3. **Knowledge Graph Summary.** Key entities, relationships, topic distances.
4. **Folder Structure.** Full hierarchy with rationale.
5. **Central Entity Template.** Exact copy for header, footer, intro, supplementary, and internal link.
6. **NLP Category Check (optional).** The site's main category and any pages that drift from it.
7. **Linking Rules Summary.** The linking rules plus client-situation-based linking decisions.
8. **Buyer Journey Gaps.** Any stages without coverage and the recommended pages to fill them.
9. **Information Gain Opportunities.** Queries and angles no competitor covers.
10. **Content Priorities.** Ordered publishing schedule (Avalanche Theory) and why this order.
11. **Off-Site Topical Authority Plan.** Link building targets, branded search strategies, media opportunities.
12. **Quality Standards.** The minimum quality bar per article. The warning about low-quality content dragging down the whole site.
13. **Dynamic Updates.** Note that the map should be reviewed quarterly as Google's indexes evolve.
14. **Folder Structure, Client Situations, Query Expansion, and Merged Attributes.** These are documented in the .md (not in separate tabs of the spreadsheet) so the user has a single strategy document plus a single spreadsheet.

---

## Final step. Present both deliverables.

When the spreadsheet and strategy document are done, present them with this short summary:

"You have two files:
1. A spreadsheet with five tabs. Open Core first to confirm your money pages. Then read AOR for your authority gaps. Then look at the Linking Map for where to route signals. Then check Buyer Journey for which stages are missing content. Then the Publishing Order tells you exactly what to ship and in what order across the next 12 weeks.
2. A strategy document. Read it once before you start writing. It has the rules of how every page should mention your business, how to link between pages, and what NOT to do.

Fix anything broken on your Core pages first (wrong intent, thin content, pages not indexed). Then start the AOR Wave: hand the first 30 content briefs to a writer, and save the big Core page rewrites until the supporting content is live. Timing varies by site, so treat the 12 weeks as a plan, not a ranking forecast."

---

**The map is dynamic, not static.** Search results change. Predicates that used to share results (like "install" and "setup") can return different result sets as Google's systems change, for example after a core update. When that happens, recheck the intent and the overlap before deciding whether they still share a page. Review and update the map quarterly.

**Research tools for Knowledge Graph work:**
- Wikipedia Graph visualiser: blinpete.github.io/wiki-graph
- Wikidata: wikidata.org
- DBpedia: dbpedia.org