SEO Neo Playbook

This is THE canonical SEO Neo + off-page operating manual for Spearleaf. It is the single source of truth, synthesized across every Clint Butler consulting session. The per-session knowledge folders are the raw record; this file is the merged, current doctrine. When a new session contradicts an older one, this file is updated and the old guidance is corrected in place (see the changelog at the bottom).

Synthesized from three Clint Butler consulting sessions: - 2026-04-08 — tactical: settings, diagrams, wizards, cloud blogs, content buckets, spin, cadence - 2026-05-27 — strategic: national vs local realism, knowledge graph, anchor strategy, heading discipline, link buying, pricing - 2026-06-05 — schema + entities (TextRazor + Google Enterprise Knowledge Graph API), cloud-template walkthrough (one URL, RD100-or-cloud), PBN safety via Cloudflare name servers, exact-match domains, external-linking reversal, significantLink, internal-linking-on-publish, Sonic + Codex build stack

This is the operating manual. Every section answers four things: what the thing is, why you do it, how to do it, and the goal it serves.

Versioning: this document is published to an internal Cloudflare Pages site. The live page is always the newest version; every time it changes materially, the previous version is archived under a dated URL reachable from the changelog button. Never edit a dated archive — only the live seo-neo-playbook.md.

Part 0 — Mental Model

What NEO actually is

SEO Neo is a desktop automation tool that runs on YOUR computer (Mac or Windows) and pushes backlinks to a fixed library of properties: cloud storage sites (S3, Backblaze, etc.), high-quality social bookmarking sites, Web 2.0 ring sites, profile sites, and PDF distribution sites. It is NOT a discovery tool. It hits the same network of properties over and over.

It has two surfaces: - Wizards — fast preset campaigns (GBP Sniper, GBP Blast, RD100, Zero to Hero, Domain Authority Stacking). - Diagram Editor — the underlying campaign builder where you can copy a wizard's diagram, strip nodes, or build your own.

NEO has two jobs (at agency scale)

Everything else in NEO is either supporting infrastructure (cloud blog network, content buckets, NAP block, spin settings) or wizards that don't actually move the needle.

Realistic timeline expectations

• DAS / brand-knowledge-graph work: 1-2 weeks per DAS run, takes 2-3 months before knowledge graph triggers.
• RD100 + cloud templates after publish: results visible in 2-8 weeks.
• GBP Blast / Sniper: weekly runs, see grid movement after 4-8 weeks.
• National SEO with NEO alone: realistically a year. Elias's case studies leave this part out.

Case studies that look like "I ran one campaign and ranked" are people who have been running NEO consistently for a long time. Most users run two campaigns, don't see rankings move, and write off the software. Don't be that user.

Goal of the whole system

Build a brand entity that Google recognizes, point a controlled flow of contextual backlinks at your client's money pages and GBP listings, then ride that flow with content that's actually structured to rank. Every action below serves one of those three goals: entity, links, content.

Part 1 — One-Time Platform Setup

Do these once. Save credentials outside the NEO install (Clint lost a setup migrating between machines because NEO has no settings export).

1.1 — Cloud API Providers (12 services, ~1 day)

What: Connect NEO to every cloud storage provider so when you create "one cloud blog" in NEO it actually deploys to 12 sites simultaneously.

Why: This is the single highest-leverage setup task. Once configured, you get 12x output per click forever. Skipping this is why most users think NEO is slow.

How: 1. NEO → Settings → Cloud API Settings. 2. For each provider, fetch API key + secret. Elias has setup videos per provider on his channel. 3. Skip Wasabi. Skip Oracle. They don't work for Clint and aren't worth troubleshooting. 4. Fill out the rest. 5. Save every credential in a password manager OUTSIDE NEO. When you move computers, you redo this whole day if you didn't.

Goal: One cloud-blog creation in NEO = 12 actual websites deployed.

Math reference: 25 cloud blogs × 12 services = ~300 sites per client folder. 155 max-tier blogs × 12 = ~1,860 sites (request Amazon bucket cap increase if you go big).

1.2 — Spin Rewriter Configuration

What: Tells NEO how aggressively to swap synonyms when spinning articles.

Why: Default settings turn one article into 1,000 garbage variants. HIGH settings produce ~50 unique high-quality variants per source article. The difference between "looks like a real human wrote it" and "obviously spun" is this single setting.

How: 1. NEO → Generate menu → OpenAI / Default Prompt area → Spin Rewriter section. 2. Set synonyms dropdown → HIGH. 3. Set the two related-words dropdowns → HIGH. 4. Save.

Goal: Every article you generate after this is reusable across ~50 campaigns without looking duplicated.

Critical caveat: Articles already generated with default settings CANNOT be retroactively spun. You have to delete and regenerate. Set this BEFORE making content.

1.3 — Default Bio Template

What: Author bio that goes on every cloud blog site.

Why: NEO's auto-generated bio is generic and obvious. The default template ships with SpinTax syntax that produces variety.

How: 1. Open a cloud blog → Default Bio → Edit My Bio. 2. Copy the entire default template (SpinTax included) to a safe place. 3. Paste into ChatGPT: I'm writing blog posts for [niche, e.g. pool cleaning services]. Here's a bio template that includes SpinTax. Rewrite this so the bio is about someone in that niche. Keep the SpinTax syntax intact. 4. Drop the rewrite back into the Bio field. 5. Save another copy of the rewritten version externally.

Goal: Each cloud blog gets a unique-looking author that matches the niche.

1.4 — Default Blog Details (Blog Names + Subdomains)

What: The pool of blog names and subdomain strings NEO uses when creating cloud sites.

Why: Greg Morrison's Reverse Sink-or-Swim rule says you want your keyword in the page title AND in the URL. The blog-name field is how you get the keyword into the URL (it bleeds into the subdomain string).

How: 1. Open Blog Details → grab existing blog name + subdomain templates. 2. Strip the numbers, leave SpinTax and structure. 3. Paste both into ChatGPT: ``` Here's the template for blog names: [paste] Here's the template for subdomain URLs: [paste]

Using the same SpinTax structure, give me 50 unique blog names and 50 matching subdomains for those names. ``` 4. Drop the resulting spin packs back in.

Goal: Cloud sites with niche-appropriate URLs that satisfy Reverse Sink-or-Swim automatically.

1.5 — NAP Block

What: Name/address/phone block that appears on every cloud blog's contact page.

Why: Plain-text lines render as a blob across the 12 different cloud providers. HTML renders correctly everywhere.

How: 1. NAP field → format with HTML paragraph tags and <br> breaks. 2. Hit Preview, confirm it shows as separated lines. 3. Untested but worth trying: drop JSON-LD schema markup in there too. Clint hasn't tested but the field accepts HTML.

Goal: Consistent, readable client info on every site in the network, possibly with schema benefits.

1.6 — Blog Comments Pool

What: Spun blog comments that GBP Blast cycles through.

Why: GBP Blast uses this pool. Spin them once at setup and never touch them again.

How: 1. Generate ~100 blog comments via NEO's generator. 2. Spinning is HIGH (already set in §1.2). 3. Save.

Goal: GBP Blast has enough comment variety to run for months without repetition flags.

Part 2 — Cloud Blog Network Setup

This is the centerpiece of the link-building side. Set it up once per client (sticky clients only) or once per niche (high-churn niches).

2.1 — The Decision: Per-Client vs Per-Niche

Joshua's situation: generalist across med spa + chiropractors + pool / home services. Recommendation: build per-niche networks. Start with a "Health Services" network (covers med spa + chiro + mental health) and a "Home Services" network (covers HVAC + plumbers + electricians + pool). About 2 days of setup buys you a reusable asset for every client in those buckets.

2.2 — Build 25 Cloud Blogs

What: 25 distinct cloud blog configurations, each producing 12 actual sites = ~300 sites.

Why: 25 is Clint's number across multiple agencies. You can technically do 155 (5+25+125 across all three tiers) but Amazon caps you at 100 buckets default, and the marginal benefit drops off.

How: For each of the 25 blog configs:

1. NEO → Cloud Blogs → Create Cloud Blog.
2. Name = a target keyword for the niche. - Health niche: "Med Spa Tips," "Chiropractor Care," "Body Treatments," "Skin Health," etc. - Home services: "Pool Cleaning," "HVAC Repair," "Plumbing Services," "Home Maintenance," etc. - For per-client: variations on the brand + service (Adam's Pool, Pool Cleaning, Pool Cleaners).
3. Social media links = client's socials (per-client) or the agency's socials (per-niche). You're building branded backlinks to those profiles as a side effect.
4. About Us + Contact Us = generic but include branded backlinks to client money sites or representative client sites.
5. Author bio = the rewritten bio from §1.3.
6. NAP block = HTML format from §1.5 (use a representative location for per-niche; use real client info for per-client).
7. Generate.

Goal: 300 niche-relevant sites whose URLs contain your target keywords, ready to serve as Tier 1 backlinks.

2.3 — Build the Elias Cloud Template Campaign

What: A NEO campaign you set up ONCE that maps your 25 cloud blogs across 155 tier slots (with intentional overlap), then duplicate every time you want to run cloud links.

Why: The Cloud Content Poster wizard only lets you select ONE cloud site per campaign. If you have 25, you'd run it 25 times. The Elias Cloud diagram has ~150 slots in one campaign — fill them once.

How: 1. Diagram Editor → find Elias Cloud template diagram. 2. Campaigns → Create Campaign. 3. Name it [client/niche]-cloud-template. 4. Set placeholder values to get through the wizard: - URL: https://www.google.com - Primary keyword: Google - Account Templates: Default - Anchor percentage: 100 5. Walk through to the diagram step. 6. For each tier slot (Tier 1 = 5, Tier 2 = 25, Tier 3 = 125): - Click the Cloud Blog dropdown next to the purple button. - Assign one of your 25 cloud blogs. - You will have overlap. That's the point — see "Why overlap" below. 7. Save the template.

Why overlap is the feature: When the same cloud blog appears in Tier 1 AND Tier 3, you're sending Tier 3 backlinks TO your own Tier 1 cloud sites. You're interlinking your network. That's what keeps cloud sites alive past the 90-day mark when other people's networks die.

Per-run usage: 1. Campaigns list → hover the template → duplicate (copy icon, top right). 2. Open the duplicate. 3. Change three things: - Target URL — exactly ONE URL per run, not multiple (Session 3 correction, 00:49:58). - Keywords (anchor text — see Part 4 for strategy) - Content bucket (the per-client bucket from Part 5) 4. Run.

RD100 OR cloud, not both (Session 3 correction, 00:50:01): For a given page, run the stripped RD100 or the cloud template — generally not both. Run both only when the keyword is genuinely hard. Earlier guidance ("RD100 + cloud template every publish") was too heavy; that's reserved for hard keywords now.

What the cloud sites are for: On a brand-new client, the 25 cloud sites exist to give the money page referring domains. They're effectively new sites with authority borrowed from the domains they sit on; the more you use and interlink them, the more powerful they get. Early on, you're just farming referring domains. (00:50:16)

Goal: One-click ~150-link campaign that hits your interlinked cloud network with proper anchor strategy, aimed at a single URL.

2.4 — Strip the RD100 Wizard

What: Duplicate RD100, remove the Authority Links node, save as a new diagram.

Why: The Authority Links node creates fresh profile accounts on every single run. Each new account triggers captcha solving. On Mac (no XEvil) this burns dollars fast. The links from this node move the needle "a little" but not enough to justify the bill.

How: 1. Diagram Editor → find RD100 wizard. 2. Duplicate the diagram. 3. Delete the Authority Links node from the duplicate. 4. Rename: RD100 (no auth). 5. Save.

What you keep: - ~15-20 high-quality social bookmarks per run - ~20-30 Web 2.0 ring sites - PDF distribution - Social bookmarking high quality (the only social bookmark tier you should ever point at client money pages)

What you give up: - Profile link backlinks. Acceptable loss for the captcha savings.

Goal: Reusable referring-domain campaign you can run every time you publish without thinking about cost.

Part 3 — Per-Client Onboarding (Days 1-3)

When a new client signs, execute this sequence in order. Goal is to clean up their existing profile, trigger brand entity recognition, and set up the systems that will run weekly.

3.1 — Social Ring Audit / Creation

What: Confirm or create branded profiles on Facebook, Twitter, Instagram, Pinterest (minimum).

Why: No social ring → no entity recognition → knowledge graph never triggers → everything else is harder.

How: 1. Check existing socials. Create what's missing. 2. Make sure usernames are brand-consistent (@brandname everywhere). 3. Fill out all fields (bio, location, website link). 4. Post at least 2-3 pieces of recent content on each so they don't look abandoned.

Goal: Google can find your brand on every major social network.

For multi-location clients: see decision tree in Part 8.

3.2 — DAS to Money Site

What: Single Diversified Authority Stack campaign pointed at the client's domain.

Why: Builds the anchor-text "pillow" — a layer of varied generic anchor text so when you start doing targeted keyword anchor work later, your ratios don't look manipulative. Also: it's a foundation for entity recognition.

How: 1. NEO → Wizards → DAS (or use a Zero-to-Hero variant). 2. Target URLs: homepage + about + contact + main category/service pages. 3. Run. 4. Plan for 1-2 weeks of run time. Don't interrupt the computer.

Cadence: ONCE. Do not repeat.

Goal: Natural-looking baseline anchor profile, brand mentions on hundreds of properties.

3.3 — DAS to Each Social Profile

What: Same DAS treatment, but pointed at each social profile URL (Facebook page, Twitter, etc.).

Why: Triggers Google to recognize your brand as an entity. The path is: take over page 1 of search results for your brand name with social profiles + third-party properties → Google starts treating you as an entity → knowledge graph triggers.

How: 1. New DAS campaign per social profile. 2. Run sequentially (or parallel if you have the hardware).

Cadence: ONCE per profile.

Goal: Brand name searches show YOUR controlled properties on page 1. Brand entity recognized.

3.4 — Zero to Hero on Money Pages

What: NEO's Zero-to-Hero wizard — runs lots of DAS + 4 Delaus + 4 Hercules in conjunction.

Why: Diversifies anchor target across homepage + about + contact + categories, so it doesn't all hit the homepage. Gives the site a baseline link velocity that looks like organic discovery.

How: 1. NEO → Wizards → Zero to Hero. 2. Multi-URL field: homepage, about, contact, top category pages (or top product categories for e-com). 3. Run.

Cadence: ONCE per new client.

Goal: Brand new site has a believable backlink profile before you start aggressive work.

3.5 — Schema Audit (Multi-Location Clients)

What: Audit page schema hierarchy so a single connected graph results.

Why: Multi-location clients with broken schema get "entity fracture" — Google can't tell which location belongs to which brand. Each page has its own local-business schema floating disconnected from the parent organization.

How: Fix the hierarchy:

Organization (parent brand)
  └── publishes Website
        └── publishes WebPage
              ├── has LocalBusiness (per location page)
              └── offers Service (per service page)

Test with Google's Rich Results Test. Whole site should validate as ONE connected schema graph. Only exception: breadcrumbs (use a plugin, it's a pain to hand-roll).

Yoast's paid local-business plugin is a reference example for proper hierarchy.

Goal: You only get ONE entity / knowledge graph per parent brand (which is correct). Maps listings per location are separate and handled by GBP.

3.6 — Indexing Hookup

What: Connect Google Search Console, Bing Webmaster Tools, Google Analytics. Send all URLs to Omega Indexer.

Why: Google will find the site regardless, but give it the data so it indexes faster and you get reporting. Omega Indexer is the kicker that gets the whole site crawled.

How: 1. Verify GSC, GA, Bing WMT. 2. Submit XML sitemap to GSC + Bing. 3. Pull every URL from the sitemap, paste into Omega Indexer. 4. Then leave it alone for 2-4 weeks. Don't fix anything yet. Wait to see what ranks easily.

Goal: Whole site indexed + crawled, baseline ranking data flowing in.

Part 4 — The Anchor Text System

Anchor text is what makes or breaks RD100 / cloud template campaigns. Get this right and 10 links move the needle. Get it wrong and 1,000 won't.

4.1 — Tier Strategy

Why: Google sees your money page being linked with mostly brand and URL anchors (natural-looking). The keyword juice comes from the supporting tiers without polluting your direct anchor ratio.

4.2 — Per-Page RD100 Anchor Plan

For any specific page you want to rank, give the RD100 campaign these three keywords as Tier 1 anchors:

1. Brand name alone (e.g. "AuraWave")
2. Page-specific topic keyword (e.g. "Princeton Headshot Research")
3. A combo phrase that mentions both (e.g. "AuraWave's take on the Princeton Headshot Research")

For Tier 2 / Tier 3 anchors: - Use H2 / H3 headings from the page as anchor text — they map to specific page sections, which Google rewards as contextual links. - Use natural-sentence phrasings ("AuraWave talked about what the Princeton research actually measured in regards to headshots").

4.2a — Cloud-Template Anchor Map (Session 3, 00:51:00 – 00:52:37)

This is the concrete anchor layout for a cloud-template run at a money page (e.g. a homepage):

• Tier 1 (the money page):
• Anchor = brand name. Set anchor percentage to 100 — you're using the brand, so you don't need variation here.
• If the homepage is optimized for one city, add a brand partial-match: "Adam's Pool and Spa, serving Long Beach." Don't lock the brand to one city if the client is expanding.
• Delete the generic plain-URL anchor nodes — DAS already built that pillow in onboarding (Part 3.2). Don't repeat it.
• Tier 2: all your keywords — exact match + variations (related searches) + entities (because it's a cloud campaign, entities are in play; see Part 13 for how to build the entity list). No real cap on Tier 2 — "go to town."

4.2b — Manual Link-Tier Anchor Counts (Session 3, 01:06:44)

If you're building tiers by hand (not just the cloud template), Clint's default counts:

Adjust to the job. Randy Roan resells this exact tiering inside a press-release product and stops at Tier 3 — "generally good enough." For a cloud run, 50–100 anchors is plenty.

4.3 — What NOT to do

• Don't use the page title as the primary anchor. That convention came from social-media OG tags (Facebook OG tank) and concentrates anchor distribution unnaturally.
• Don't use NEO's Keyword Buckets feature. Clint doesn't use them at all.
• Don't run a single-keyword anchor blitz on a money page — that's a maps-only tactic (see Part 6.4).

4.4 — Why "10 links beats 1000 links" works

Your competitors push 1,000 links because their on-page is shit and they're brute-forcing. If your on-page + schema + heading structure is right (Parts 3.5 + 7), 10 properly-anchored links move the needle. Another 10 moves it more. Another 10 again.

Save your link budget. Spend it on quality, sent slowly.

Part 5 — Content Bucket Strategy

The bucket holds the spun articles NEO uses to fill cloud blogs and ring sites with content. The default-internet advice is one bucket per keyword, 1,000 articles each. That's wrong.

5.1 — One Bucket Per Client / Per Niche

What: A single content bucket per client (or per niche if reusing networks).

Why: Adjacent topics cross-pollinating doesn't hurt rankings — they're in the same semantic neighborhood. A pool filter article linking to a pool cleaning page is fine. Separating buckets per keyword multiplies your work 10x for zero benefit.

How: 1. NEO → Content Buckets → Create Bucket. 2. Name it clearly: [Client] - [General Service]. Example: Adams Pool and Spa - Pool Services. 3. Set article generation to use Spin Rewriter (HIGH from §1.2).

Goal: One bucket selector to pick during campaign duplication. Zero overhead.

5.2 — Weekly Growth Pattern

What: Add a new topic to the bucket each week instead of frontloading everything.

Why: It keeps the content fresh, lets you target whatever you're actually optimizing that week, and slowly grows the bucket into a useful library.

How: - Week 1: pick topic (e.g. "commercial pool cleaning"). Generate 50 spun articles. Add to bucket. - Week 2: next topic (e.g. "pool filter maintenance"). 50 more. Same bucket. - Week 3: 50 more. Same bucket. - After 10 weeks: ~500 articles in bucket, all reusable.

Why 50 not 1000: With Spin Rewriter on HIGH, each source article produces ~50 unique variants. 50 source articles × 50 variants = 2,500 effective uniques. More than enough.

5.3 — Article Generation Sources (Find Topics That Will Rank)

What: Use SEMrush keyword gap analysis to identify topics your competitors rank for that you don't.

Why: Faster than studying SERPs manually. Reveals where competitors are getting traffic, which you can then beat with better-structured pages.

How: 1. SEMrush → Keyword Gap tool. 2. Domain 1: your client's site. Domain 2: top competitor. 3. Hit Compare → filter to Missing keywords. 4. Filter for questions ("best AI headshot generator," "do AI headshots work"). 5. Read the SERP for each promising keyword. If results rank because they're Medium / Reddit / Canva / Apple / Quora / YouTube → you can beat them. They're ranking on domain authority, not content. 6. SEMrush will show you suggested headings for that keyword. Now you're targeting 5+ keywords per article instead of 1.

Goal: Article topics with proven traffic that you can outrank using the Part 7 heading + Q&A discipline.

5.4 — Writing the Article (Claude Workflow)

For each topic, write the article using this prompt sequence in Claude:

Step 1: Audit a competitor page

Examine this web page: [competitor URL]
The primary keyword is: [keyword]
Review the heading tags and identify the ones that are not related
to the primary keyword. Suggest rewrites.

Step 2: Get the new heading outline

Taking what you just gave me and the headings we didn't have to change,
give me the new heading tag outline.

Step 3: Rewrite using Q&A paragraph format

This is a question. The heading is the question.

In the first paragraph:
- First sentence: directly answer the question.
- Second sentence: provide a source for the answer.
- Third sentence: example of applying the information.

Rewrite the article implementing that new formatting requirement.

Why this works: see Part 7.

Part 6 — Maps / GBP Operations (Weekly Cadence)

The high-frequency loop. This is where you generate the phone calls that pay the agency. Once per week, every client.

6.1 — Goal of the GBP System

Push the client's Google Business Profile pin to top-3 (the "map pack") for high-intent commercial keywords in their service area. Phone calls follow.

6.2 — Step 1: Rerun the Grids (Weekly)

What: Refresh every client's GBP heat-map grid in NEO so you can see current rankings per pin location.

Why: - Without recent grid data, NEO's programmatic targeting is blind — it sends links where they're no longer needed. - With recent data, NEO automatically pushes links toward weak pins (e.g. ignores all your #1 pins, focuses on the #10s).

How: 1. Open each client's GBP grid in NEO. 2. Hit "Rerun" (it costs credits — accept it). 3. Don't trust the color legend. Click into the grid to see actual numbers. A "5" might show green but isn't 3-pack.

Cadence: Weekly for active push. Monthly minimum for maintenance.

6.3 — Step 2: Pick the Weak Keywords

What: Review each client's grid list and identify which keywords are red and worth pushing.

Why: Not every red keyword is worth chasing. "Team headshots" might be red because companies hire their own photographers — no commercial intent. Pick the reds that have actual buyer demand.

How: 1. Look at every keyword in the client's grid set. 2. Flag the red ones. 3. Cross-reference with commercial intent: "LinkedIn headshots" yes, "team headshots" no. 4. Prioritize 3-4 keywords to rotate through.

6.4 — Step 3: Run a Single-Keyword GBP Blast

What: GBP Blast campaign with exactly ONE keyword as the primary anchor.

Why: The map is the only place you can get away with concentrated single-keyword anchor pressure. Your money site cannot — same tactic on the site would over-optimize and tank you. The map can absorb it.

How: 1. NEO → Wizards → GBP Blast. 2. Campaign selection → your client's GBP. 3. Primary keyword: ONE word/phrase only (e.g. "LinkedIn headshots"). Not "LinkedIn headshots near me," not variations. 4. Run.

6.5 — Step 4: Rotate Weekly

Why: A 4-week rotation across 3-4 keywords gives the map sustained pressure on each commercial term without overweighting any single one.

How: - Week 1: "LinkedIn headshots" - Week 2: "Professional headshots" - Week 3: "Commercial photography" - Week 4: Rerun grids. Has a previously-good keyword (e.g. "team headshots") slipped? Add it as a fourth keyword and rotate it in.

Now you're running ~4 blasts/month, all containing the core noun ("headshots") plus niche-specific differentiation. Anchor diversity-with-coherence.

6.6 — GBP Sniper

What: Companion to GBP Blast, runs once a week alongside.

Why: Different mechanism, complementary effect.

How: Run alongside GBP Blast on the same weekly cadence while in active push mode.

6.7 — Switching to Maintenance Mode

When: Grids show consistent top-3 across your priority keywords.

Cadence shift: Drop from weekly to monthly GBP Blast + Sniper. The reason: GBP Blast hits the same network of sites over and over. If you stop for 3+ months, the backlinks roll off and rankings fade.

Bake into SOP: monthly GBP Blast for EVERY client regardless of current ranking. Freshness maintenance.

Two refinements from Session 3 (00:42:46 – 00:49:00): - One map per city, not one giant map. A Phoenix map will never rank you in Scottsdale even though they're adjacent — you need a separate Scottsdale map. At some point a single grid stops giving more results; spreading to a neighboring city's grid is the next move, not pushing the same grid harder. - Leave near-perfect grids alone. If a grid is all 1s except one tiny corner at #4, don't keep working it — drop to a once-a-month maintenance blast. Others are always trying to rank, so maintenance keeps you from sliding, but chasing that last corner is spinning your wheels. (City/neighborhood WordPress tags + a little service-area schema help a bit, but only a bit.)

Part 7 — On-Page Discipline (The Other Half of Why 10 Links Work)

Clint's claim: "I only care about referring domain count when I'm first publishing. After that it's on-page + schema, and then 10 at a time good links." This part is the on-page side.

7.1 — Heading Tag Discipline

What: Every heading on a page should tie to the primary keyword or be a subheading of it.

Why: Google scans a couple trillion websites and uses minimal-viable-crawl heuristics. Every heading is a signal about what the page is about. "About the Author," "Read Next," "100 Millisecond Verdict" are noise that confuses Google's read.

Web developers add H2 tags for visual consistency (same font everywhere). Google doesn't care about visual — it cares about semantic outline. Strip the styled-as-H2 noise.

How — write headings like a research paper outline: - H1: main topic / introduction - H2: subtopics - H3: sub-subtopics within H2s - H4: conclusion

For any existing page: 1. Run the Claude prompt sequence from §5.4 step 1. 2. Identify wasted headings. 3. Rewrite or demote them (some become regular paragraph text, some get removed).

Goal: Google reads the outline of your page and immediately understands what it's about. You don't fight Google's classifier.

Bonus: If you hand an AI an outline (vs. "write me an article about X"), output is dramatically better. The outline IS the article structure.

7.2 — Q&A Paragraph Format

What: Three-sentence paragraph structure under each heading.

Why: Triggers People Also Asked citations and AI answer-engine citations. AI is an answer engine — it goes to sources, correlates, cites. This format makes you the citation.

How: For each H2/H3 that's phrased as a question (or that you can rephrase as one):

• Sentence 1: Directly answer the question.
• Sentence 2: Provide a source for the answer.
• Sentence 3: Example of applying the information.

Credited to "Corey" by Clint (says he's a con artist but this one tactic is real).

Goal: Capture PAA placement + AI overview citations + match how Google actually reads structured content now.

On AEO / getting cited by AI (Session 3, 00:12:21): This Q&A format is the one durable AEO lever. Clint tried every published AI-citation tactic and got inconsistent results; what actually worked was stopping chasing them, running standard SEO well, and letting the citations come on their own. llms.txt (Brian Winnham's "LLM TXT") is worth a low-priority test but may be more work than it's worth when citations already arrive naturally. Don't build an AEO program; build good SEO with this format baked in.

7.3 — Schema Hierarchy Discipline

Already covered in §3.5 for multi-location. For single-location:

• Homepage: Organization schema (parent) + Website schema published-by Organization.
• WebPages: WebPage schema, part-of Website, published-by Organization.
• Service pages: Service schema attached to LocalBusiness.

Test in Rich Results: should validate as ONE connected schema graph.

The three levels of schema (Session 3, 00:14:14 – 00:20:02):

Advanced schema is a last-ditch on-page lever: you've done on-page, you've done Cora/POP — now "let me see how schema does" before you spend money on backlinks. Market sophistication decides how far you go.

Don't believe "AI loves schema because it's JSON." There is zero empirical proof. AI can leverage schema to understand a page the way a search engine does, but it does not cite you because you have schema. Treat every such claim as a hypothesis to test, not a fact. (00:24:33)

The full entity-extraction → machine-ID → schema → significantLink workflow lives in Part 13 (it's substantial enough to be its own part).

7.4 — External Linking Rule (Session 3, 01:35:27 – 01:37:00)

Stop generic external linking. Clint's testing showed it does nothing.

• Never default to Wikipedia. An all-Wikipedia external profile reads as manipulation — Google caught onto it. Clint even pulled Wikipedia out of his schema.
• Link only to genuinely cited sources. Example: a Phoenix weather article that mentions the National Weather Service links to the NWS Phoenix page — a real cited source, not "linking to link."
• If you wouldn't cite it in a research paper, don't link it.

7.5 — Internal Linking Is a Publish Step, Not a Cleanup (Session 3, 01:32:55 – 01:35:11)

"If you don't link to your new piece of content, why should Google index you?" — Clint's theory for why most people's indexing is bad.

On every publish: 1. Publish the new page. 2. Link OUT from the new page to relevant existing pages. 3. Link IN — update older content to link to the new page. This is the priority. 4. Then everything else.

Why it matters: internal linking from old content is part of the indexing algorithm. A page that's been live 90 days with no internal/external links is a deindex signal. Enough deindexed pages and your site score drops, and then you don't rank for anything.

For HTML/Eleventy sites: bake "link old → new" into the publish script the way Clint's WordPress script does (publish → link out → link in). Do not rely on a monthly "find unlinked articles" pass — it has to happen at publish time.

7.6 — When to Apply All This (Triage)

You can't fix every page. Pick the ones that matter:

• Don't touch: pages already ranking top 3. Pages with zero rankings (not even page 5).
• Do touch: pages ranking 11-25. They're close. Fixing the heading + Q&A structure usually pushes them up.

Workflow: Pull GSC data → filter pages 11-25 → run Claude heading audit → publish updated version → run RD100 (no auth) or cloud template at the updated URL (both only if the keyword is hard).

Part 8 — Multi-Location Decision Tree

When a client has multiple physical locations.

8.1 — Decision

One brand + multiple locations + ONE website → 1 social ring + N GBPs + 1 entity / knowledge graph. → Use Organization schema (parent) + LocalBusiness per location. → Post unique content per GBP. Run general posts on Facebook that work for all locations.

Franchise-style: separate brand names per location + separate websites → N social rings + N GBPs + 1 entity per brand. → Each gets its own DAS sequence in Part 3.

Entity fracture in apps like Apple Maps / TripAdvisor → Fix with schema (§7.3), not by creating fake separate brands.

8.2 — Why This Matters

Without correct schema, multi-location clients hit "entity fracture" — Google can't tell which location belongs to which brand. Map listings end up duplicated, knowledge graph never settles.

You only ever get ONE entity / knowledge graph (the parent brand). Map listings per location are separate, handled by GBP. Don't try to force a knowledge graph per location.

Part 9 — Link Buying (When On-Page is Done)

Don't spend a dollar on links until Parts 7.1-7.3 are clean. Otherwise you're throwing money away.

9.1 — Budget Tier Decision Tree

Under $1K budget, just starting out: → QGP (~$100/link). What the links are is what they are. → After buying, run NEO cloud-bucket campaign at each purchased link to amplify (Google needs to see the purchased page has links of its own, otherwise it devalues).

$2K+ for a single push, target page already converts: → Grindstone SEO (grindstoneseo.com). ~$2K for 10 good links, parasite links, often rank on their own merit. They vet your site first — won't sell if you have other issues. Clint's mastermind member.

Built your own PBN via expired domains: → Don't bother. Hosting + maintenance + populating cost more than buying.

9.2 — Link Target Evaluation Rules

Before buying ANY link, check:

• Does the host site have ANY traffic? Does it rank for ANYTHING? Yes = Google "kinda likes it." Good enough.
• Does the host internally link to its other guest posts? If not, walk away — Google devalues unlinked content. A bought link with zero internal links into it = $100 for an S3 bucket essentially.
• Is the host in a relevant niche? Same-niche links carry more weight than random general sites.

9.3 — Cadence

10 good links at a time. Watch ranking. Another 10. Watch. Another 10.

Not 100 in one shot. Not 1000.

9.4 — Amplify Purchased Links with NEO Cloud Buckets

After buying 10 links, run a cloud bucket campaign pointed at EACH purchased link's URL.

Why: Sends backlinks to your purchased backlinks. Increases the value Google sees in them. Otherwise, your $100 purchased link is just a page with one outbound link — Google devalues it.

Part 10 — Cadence Cheat Sheet (Master SOP)

This is the daily/weekly/monthly rhythm.

Per New Client (Onboarding, Day 1-3)

Then leave alone 2-4 weeks. Watch what ranks.

Weekly (Every Active Client)

Every Time You Publish a New Article

Monthly (Every Client, Even Top-3 Maps)

Indexing Split (Always)

• Tier 1 (links pointing at money pages) → Omega Indexer.
• Tier 2 / Tier 3 (supporting links) → Coalindexer.

Don't pay Omega rates for spam-tier sites Google won't truly index anyway. You just need them crawled.

Part 11 — The Don't Do List

Things that look reasonable but actively waste time or money.

Part 12 — Strategic Decisions to Make (Open Questions)

These came up in both calls and aren't yet decided.

12.1 — Niche Down or Not

Clint doesn't niche but acknowledges it costs him. Joshua needs to decide before next session — Clint won't have the pricing conversation until a niche is picked.

If Joshua niches → leading candidates from the calls: med spa + chiropractor + general health. Build a Health Services cloud network. Pricing benchmark: probably $1,500-$2,500/mo, higher than home services.

12.2 — National Play on aurawave.ai

Clint's verdict: with NEO alone, plan for a year. Faster requires paid link budget. Get on-page right first (heading discipline + Q&A format), trigger knowledge graph via socials, then go to Grindstone with $2K for 10 quality links per money page.

12.3 — Directories as PBNs

"Directories now are the new PBNs." Worth pursuing IF Joshua niches into health.

Use directories owned by Joshua as citation sources for his agency clients in that niche. Avoids paying for external citation services.

12.4 — Pricing Tier Strategy

Once niche is picked:

3-column pricing table: - Cheap ($1,500 or niche floor): minimal features. Anchors price perception low. - Recommended ($2,500 or target): most features. What you want them to pick. - Crazy expensive: anchors price perception high. Makes Recommended feel reasonable.

Goal: most prospects pick the middle.

12.5 — Margin Reality with AI

• Content cost: near-zero now with Claude. Used to be the #1 expense in rehab work.
• Web design cost: WordPress site that cost $1,500 to build now takes 3 days + $100 Claude subscription. Margin is good.
• Backlink budget: still the largest line item. Plan accordingly.

Part 13 — Entity & Advanced Schema Workflow

The Session 3 centerpiece. This is how you go from a web page to a list of Google's machine-readable entity IDs to a finished schema block. Reserve the full version for sophisticated markets (lawyers, rehab) and roughly one page a month per client; the fast version is fine for everyday cloud anchors.

13.1 — Why Entities

Pages can rank on schema alone when the schema cites real entities. The payload that moves rankings is the About node (what the page is about) + the Mention node (what it mentions), each citing entities by their machine-readable ID — the /m/... numbers Google attaches to knowledge-panel entities. Organization schema is table stakes; the mentions and citations are what kicked Clint's pages to the top. (00:20:30)

History: Google bought Freebase.com (a Wikidata-like site), closed it, and built the knowledge graph + machine IDs from it. (01:19:00)

13.2 — Get the Entity List (Fast Method)

Use this for everyday Tier 2 cloud anchors and GSA anchors.

Option A — ChatGPT + Wikidata (ChatGPT is more of a technical advisor than Claude here):

Review this web page: [URL]
Look for known entities that can be cross-referenced on Wikidata.
Give me a list.

Keep topical entities (e.g. "swimming pool sanitation") + target cities. Skip government-list items and reaching neighborhoods; use brand names (Pentair, etc.) sparingly.

Option B — TextRazor (textrazor.com): 1. Install a Reader Mode Chrome extension; refresh, enable it. 2. Reader-mode the page → Ctrl-A → copy. 3. textrazor.com → Try the demo → paste → Analyze. 4. The entities on the right are your list (same as POP / Surfer semantic terms).

Format for NEO: ask the AI for "a line-by-line list in a code box," merge new + old, and add your expansion-market cities. Mentioning + anchoring to those cities shapes the topic toward them with your backlinks. (01:01:09)

13.3 — Get Machine IDs (The Right Method)

For hard niches, upgrade from Wikidata strings to Google's machine IDs.

1. In Google Cloud, enable the Cloud Enterprise Knowledge Graph API. There are two — one is deprecated; use the Enterprise one (they look identical). (01:02:30)
2. Free account → API key → pay-as-you-go. Pennies for normal use, ~500 free credits/day (hard to burn). Don't feed it a whole website — "Enterprise" pricing is real. (01:03:05)
3. Use it on ~10 competitor articles to find the common entities (a cheap homemade Cora/POP) and have it write the schema. (01:04:01)
4. Verify a machine ID by hand: Google the entity → View Source → Ctrl-F /m/. Example: Google = /m/05045c. That number is the entity to the algorithm. (01:20:12)

13.4 — Build It in Codex, in Stages

1. Use Codex (ChatGPT), reasoning extra high. (Clint prefers it over Claude Code and rarely hits limits on the cheap plan.)
2. New chat, no project context.
3. Never one-shot. Build in stages: (01:11:25) - Stage 1: Python script → Enterprise Knowledge Graph API → read a URL, list entities (paste the API doc link). - Stage 2: cross-reference that list against another tool (e.g. TextRazor) to verify. - Stage 3: generate the schema from verified entities.
4. Security: never paste the API key inline — have it create a .env. (Spearleaf shares keys to the team via Doppler so no one sees the raw values.)

"When you one-shot with coding, that's where you end up chasing rabbits all day long. Map out what you're trying to develop and the steps."

13.5 — Clean the Schema + Add significantLink

1. Run the page through Zista (or the Codex script) → About + Mention schema citing entities by machine ID.
2. Read the output — it adds junk. Keep relevant entities, drop noise, sort by relevance, remove single keywords, leave Wikidata refs. Save. (Duplicate schema on a page still works, but don't do it on purpose.)
3. Add significantLink. Google reads it as a backlink and it surfaces in search. On cloud pages, point a significantLink at the client's money site. (01:25:06, 01:39:00)
4. Place it: HTML → paste into the page. WordPress → SEOPress Pro per-page, or WP Code site-wide.

"Some schema is better than no schema, and this is a pretty good schema." Don't hand-craft unless the market demands it.

13.6 — Tools in This Workflow

• TextRazor — free entity extractor (Wikipedia-backed).
• Google Cloud Enterprise Knowledge Graph API — machine IDs, pay-as-you-go.
• Zista.com (Muhammad; absorbed TopicalRelevance.com by Joshua Priest) — About/Mention schema generator. Jesper Nielsen has a competing tool Clint declines to recommend.
• schema.org itself — the real skill. Learn schema.org/website and you can build anything; templates per niche are just a starting point. Clint's course on whatRanks.com teaches schema.org, not templates.

Part 14 — Network & Infrastructure Safety

How to run a domain network and host client sites without getting caught or trapped.

14.1 — Hide a Network in the Noise (Cloudflare Name Servers)

Greg-Morrison-style PBNs get caught: trash-looking sites, same IP, same registrar, no privacy. Garrett Alcott's safer method: (00:30:10 – 00:32:47)

1. Turn on WHOIS privacy on every domain — now the only link left is the IP.
2. Add each domain to Cloudflare. It assigns one of ~13 different name-server sets and rotates across many IPs; millions of sites share each name server, so there's no clean way to tie your domains together.
3. Free, and Cloudflare is worth having anyway.

Building a full Greg-Morrison PBN is a ton of work and only pays if you sell links. FoxNews owns ~17,000 domains all linking to itself — a PBN, but they're real publishers, so they're fine. Be the real-publisher version.

14.2 — Exact-Match Domains

• Exact-match / keyword domains rank well right now despite the "stay away" chorus — you see them all over local search. (00:36:45)
• The catch: link-building with exact-match anchors. Google is sensitive to them (not hostile). You must pillow the anchors with DAS — use a lot of them. (00:36:23)
• Cheap test: spin up one-pagers (legal pages + contact form, to address EAT) on Cloudflare Pages for a niched client's spare domains, let them run, and promote any that rank to a real host. They're the client's domains, so no cost if they fry. (00:37:55)

14.3 — Own the Racecourse

(James Schramko's rule.) Own your platform; don't bet a business on a free tier you don't control. (00:38:12)

• Free Cloudflare Pages is great for testing, but own your hosting before a real business depends on it. (Cloudflare's $20/mo is still cheaper than typical hosting; you can also buy single features, e.g. Argo at $5/mo.)
• Never take control of a client's domain or hosting. The Sesame dental-CRM story: free redesign, contract says they own 95% of your content, they talk you into transferring your domain — quit and you lose content, CRM, and domain. If the client controls domain + hosting, they always own their business and you avoid the drama. (00:42:48)

14.4 — Turbo Subdomains (TSD) — Optional Scale Tool

Garrett Alcott's subdomain-network tool. License $2k–$10k + $197/license; Clint paid ~$3k for 2 sites × 500 subdomains = a 1,000-site network at ~$500/mo. The value is auto-publishing (sites are always doing something); DIY and you own the publishing problem. System is janky — turn-and-burn for now. With Sonic + Claude you could replicate it (design → template → all subdomains → default pages → topical map per site → 150 scheduled posts = ~2 years of content). (00:43:00 – 00:44:46)

14.5 — Client Reporting

Clint tells clients up front: no reports. He installs a change-history plugin so they can see exactly what he's doing, and they already have GSC + GA. No reason to bill for restating free data (he can export the change log as a report if a client insists). (01:28:00)

Part 15 — Build & Automation Stack

15.1 — Sonic (AI Web Builder)

Ravik's Sonic (he also makes MapPack Toolbox) hooks Claude into the terminal, interviews you about the brand, ships a base design, then you talk it into fixes. (Clint's invite: https://sonic.saasperity.com/signup?code=CB-HC8P.) (00:00:48 – 00:11:34)

• ~$1k. Clint rebuilt his agency site (with WooCommerce) in 3 days and made it back on the first client rebuild.
• Can do 200-page builds but isn't shoehorned into a number — tell it more or less. Exports WordPress themes, works with Elementor, Shopify coming.
• Out of the box it's weak at content + CRO. Clint added his own skills/prompts to make it good at content, CRO, and SEO.
• Don't make 200-page sites for a network — you can't link to all those pages well. Just because it can doesn't mean you should. (00:28:15)
• Margins improve only if you already know what "right" looks like; the public can make sites, but not sites that convert.

15.2 — Codex over Claude Code

Clint's preferred coding agent. Reasoning extra high, build in stages (Part 13.4). On the cheap plan he's hit limits ~twice.

15.3 — Clint's Publish Automation (Reference Architecture)

Runs from PyCharm, Tue/Fri: topic research → API analyzes relation to the customer → write article → generate images → set up SEOPress Pro fields → he reviews + publishes → button builds internal links from older content to the new post. 1 hour/client → 5 minutes/client. On review he checks the SEOPress Pro fields are actually filled (Yoast→SEOPress migrations leave shortcode fields empty) and sets the featured image. (01:12:49 – 01:14:04)

15.4 — Direct-Mail Prospecting

Joshua's pipeline: scrape company site + GBP → rebuild the page → auto-screenshot old vs new hero (mobile + desktop) → postcard template → email the rebuilt site + mail a postcard + phone follow-up. Lob.com sends ~500 postcards for ~$500 with no monthly sub. James Slattery closed clients on a single Dan-Kennedy-style mailed packet (grid map + screenshots), no follow-up. Clint's advice: pick local businesses in the $1,500–$2,500 range and stop there; higher-touch (email + phone) needs a higher base price to justify the work. (00:04:08 – 00:08:04)

Part 16 — Tooling Checklist

Part 17 — Glossary

• DAS — Diversified Authority Stack. NEO campaign that builds a "pillow" of generic anchor backlinks to set up natural-looking ratios.
• RD100 — Referring Domain 100. NEO wizard that targets ~100 unique referring domains per run. Strip the Authority Links node.
• GBP Blast — NEO wizard that pushes backlinks to a Google Business Profile via a fixed network of sites.
• GBP Sniper — Companion to GBP Blast, different mechanism, runs alongside.
• Zero to Hero — NEO wizard for brand-new client kickoff. Runs DAS + 4 Delaus + 4 Hercules.
• Domain Authority Stacking — NEO wizard that pumps plain URL anchors (no keywords). Fixes over-optimized anchor profiles.
• Elias Cloud — Diagram template inside NEO that maps 5+25+125 cloud sites across 3 tiers.
• Cloud Blog — In NEO terms, one cloud blog config = one site per connected cloud API. With 12 APIs, "one cloud blog" = 12 actual sites.
• Cloud Bucket — NEO term for cloud sites (S3, Backblaze, etc.) holding HTML files that act as backlink sources.
• Reverse Sink-or-Swim — Greg Morrison's rule: want your keyword in BOTH the page title AND the URL.
• Knowledge Graph — Google's entity recognition. Your goal: get Google to recognize the brand name as an entity, not just a string.
• Entity Fracture — When Google can't tell which location belongs to which brand because schema is broken. Fix with proper Organization → LocalBusiness hierarchy.
• Content Bucket — NEO's content pool for articles. ONE per client/niche, not per keyword.
• SpinTax — {this|that|other} syntax for spun-text variants.
• Q&A Paragraph Format — Sentence 1 answers, Sentence 2 sources, Sentence 3 applies. Triggers PAA and AI citations.
• PAA — People Also Asked, the question accordion in Google SERPs.
• OG Tag — Open Graph tag. Social-media metadata that drove the old "use page title as primary anchor" advice.
• NAP — Name, Address, Phone. Local SEO baseline.
• Entity — A thing Google recognizes in its knowledge graph (a place, org, concept), distinct from a keyword string.
• Machine-Readable ID — Google's /m/... identifier for an entity, found in knowledge-panel page source. The most precise way to tell Google which entity you mean.
• About / Mention Schema — Schema nodes declaring what a page is about vs. what it mentions, each citing entities. The payload that ranks pages on schema alone.
• significantLink — A schema.org property Google reads as a backlink; surfaces in search. Point cloud-page significantLinks at client money sites.
• Exact-Match Domain (EMD) — Domain that is the target keyword. Ranks well now; requires DAS anchor pillowing because Google is sensitive to exact-match anchors.
• Own the Racecourse — James Schramko's rule: own your platform/hosting/domain; never depend on (or seize) someone else's.
• Sonic — Ravik's AI web builder that drives Claude in the terminal to build/rebuild sites.
• Codex — ChatGPT's coding agent; Clint's preferred tool for building SEO scripts.
• TextRazor — Free entity-extraction tool used to pull anchors/entities from a page.
• Knowledge Graph API — Google Cloud API returning entity data + machine IDs. Use the Enterprise one, not the deprecated one.
• TSD / Turbo Subdomains — Garrett Alcott's auto-publishing subdomain-network tool.

Changelog

What This Playbook Doesn't Cover (Yet)

• Specific cloud API setup per provider (watch Elias's videos).
• XEvil install + wiring to NEO (Windows-specific).
• Garrett Alcott's TSD system internals (Part 14.4 covers the what/why/cost, not the setup).
• N8N / Mark Rabinovich syndication workflow specifics.
• Pricing strategy specifics by niche (deferred until next Clint session — niche must be picked first).
• Agency growth tactics, how to secure franchise contracts (Clint can cover next session).
• Directory build specifics for the health niche.
• schema.org literacy deep dive (Clint's whatRanks.com course) — Part 13 gives the workflow, not the schema.org fundamentals.
• llms.txt implementation + whether it's worth it (pending Joshua's test).

Update this playbook as those gaps fill from future sessions.