- NO.
- 020
- DATE
- READ
- ~8 min
- KIND
- Guide
- STATUS
- Reviewed
Multi-Site SEO: a 30-Day Plan and 3 Templates
The execution kit for multi-site SEO governance: who arbitrates conflicts, how the 30 days are scheduled, and three copy-ready templates.
This is the execution kit for Multi-Site SEO Governance: Clusters to 301s.
The main post answers how to decide: which conflicts to merge, which to differentiate, how long a 301 stays up, what order to work cross-domain problems. This one answers how to ship it: who does the work, how the 30 days are scheduled, and what the tables look like.
As in the main post, [FRAMEWORK] marks methods that are mine. Use them as a default starting point, but they are not a Google standard and have not been validated by a controlled experiment. If your data says otherwise, follow your data.
Three terms to agree on first
You can use this post without reading the main one, provided you accept three definitions:
- Keyword cluster: a set of queries that one page can satisfy. The unit is a demand, not a phrase. The grouping test — five criteria plus SERP overlap — is in the main post.
- Primary domain and primary page: a high-value cluster gets exactly one domain and one core page carrying the procurement intent. Other sites may only publish supporting content.
- Freeze: stop creating same-intent pages on the weaker site, while leaving existing pages untouched — no deletion, no
noindex, no 301 — and observe for 8–12 weeks. A freeze is reversible, and that is its entire value.
Deciding whether two pages should both stay, be differentiated, or be merged is the decision tree in the main post; it is not repeated here.
Who owns it: federated governance for a team of 7–8
[FRAMEWORK] This whole section is a method I derived from how search actually works plus the realities of team coordination.
A small team running a dozen sites cannot use full central control or full autonomy: the first makes the center a bottleneck, the second is exactly the "every site grabs whatever keyword it likes" mess. The workable middle is federated — the center decides who owns each cluster, each site keeps day-to-day autonomy.
| Role | Headcount | Owns | Does not own |
|---|---|---|---|
| Central owner | 1 | Domain charter, cluster registry, cross-site rules, conflict arbitration | Day-to-day content and optimization on any site |
| Site owners | 5–6 | Their site's content, optimization, inquiry conversion | Final say on cross-site allocation |
| Data / technical support | 1 | GSC/GA4/CRM plumbing, extraction scripts, gate checks | Content judgment |
Three operating rules:
- A lightweight check before publishing a new page, three items only: is the
clusterIdregistered, is this site the cluster's primary domain, and does the title contain procurement-intent terms (supplier/manufacturer/price/for sale/buy) while this site is not the primary domain? Not a full editorial review — the target is a verdict within minutes. A slow review is a review people find ways around. - Cross-site conflicts are arbitrated by the central owner, with an SLA: a verdict within five working days, stating the basis (which cluster, which data was examined, why it went to this site). Verdicts must be written down; the next conflict of the same kind is settled by citing them.
- Dual-track performance measurement: site owners keep their own inquiry targets and carry a global metric (total qualified inquiries across all sites, or across the top 20 clusters).
Rule 3 decides whether the whole model works. If conceding a cluster to another site directly lowers a site owner's numbers, no rule will hold — not because people are uncooperative, but because the rule is asking them to damage their own interests, which is not sustainable. You can test this causal chain yourself: check whether your performance structure punishes the correct behavior before you discuss anyone's execution.
Action for this section: put real names in that table. If you cannot fill in "central owner," do not start multi-site governance — solve the authority problem first.
The 30-day plan
[FRAMEWORK] Every week has a deliverable and an exit criterion. Do not enter the next week without meeting the current one.
Week 1: inventory
- Produce the domain list: domain, product line, target market, site owner, and whether GSC/GA4/CRM access is actually wired up.
- Tag each site
active/reposition/shutdown candidate, using the three questions: if it went dark, would customers lose something unavailable elsewhere? Does it have its own product data and quoting process? Can you state the demand it serves in one sentence that does not duplicate another site's? - Identify the 3–5 genuinely active core sites (updating, with traffic, with inquiries).
- Configure BigQuery bulk export for every site in the same week. This step gets deferred easily, but it does not backfill — the first batch starts accruing within 48 hours of a successful setup, and everything before that is gone for good. Configuring today versus next month is a month of data.
Exit criterion: every domain has an owner's name and a known access status. No "not sure" entries.
Week 2: build the clusters
- Export six months of GSC data through the Search Analytics API (
rowLimit25000,startRowpaging). Bulk export cannot give you history, so this step has to go through the API. - Normalize, cluster, and use the main post's scorecard to select the top 20–50 high-value clusters.
- Identify the 10 most obvious conflicts (clusters where two or more of your own pages compete).
- Run each through the decision tree and write down the verdict.
Exit criterion: every conflict has one verdict (keep both / differentiate / merge + 301) with its basis written down.
Week 3: pilot
- Pick one product cluster. Run three at once and you will not know which action produced which result.
- Complete the differentiation or single-page merge using the 301 checklist in "Three copy-ready templates" below. Back up first.
- Execute the freeze on the weaker site: no new same-intent content, existing pages untouched.
- Record the baseline: pre-merge impressions, clicks, average position, landing-page key events, inquiries.
Exit criterion: the 301 has been verified with curl -I against the real domain, and the baseline data is archived.
Week 4: verify and institutionalize
- Check four layers: crawling (has GSC fetched the old and new URLs), indexing (has the old URL stepped aside), ranking (the cluster's average position trend), conversion (landing-page key events and sales feedback).
- Choose one of three: replicate on the next cluster / adjust and retry / roll back.
- Establish the monthly cross-site review. The monthly report structure I use is published as a template — GSC / GA4 SEO monthly review template — and adapts directly to a multi-site version.
- Ship the three publishing-gate checks from "Who owns it" above.
Exit criterion: next month's review is on the calendar with a named chair.
One expectation that has to be stated
Four weeks is not enough to see stable ranking or inquiry movement. Week 4 checks whether the actions were executed correctly and whether the direction is obviously wrong — not whether it worked. Real effect assessment takes 8–12 weeks, and it is read at the cluster level, not per keyword. Any multi-site programme promising results in 30 days is selling an illusion.
Three copy-ready templates
A. Cluster registry
CSV header, ready to paste into a spreadsheet:
cluster_id,intent,market_locale,primary_domain,primary_url,allowed_scope,owner,status,last_review,score,inquiries_6m
Filled in, it looks like this:
| Cluster ID | Demand / intent | Market & language | Primary domain & page | What other sites may do | Owner | Status | Last review |
|---|---|---|---|---|---|---|---|
| PAL-HYG-001 | Hygienic pallet procurement | EN / US, UK | Site B /hygienic-plastic-pallet/ | Food-industry cases and cleaning guides allowed; no new same-intent procurement page | Zhang | active | 2026-07 |
| PAL-HD-002 | Heavy-duty pallet procurement | EN / EU | Site A /heavy-duty-pallet/ | Warehouse automation applications allowed; no new procurement page | Li | active | 2026-07 |
| PAL-HYG-003 | How to clean pallets | EN / global | Site B /blog/clean-plastic-pallets/ | Any site may cite and link; no same-title page | Zhang | watching | 2026-06 |
(The example data comes from the fictional pallet company in the main post and represents no real client.)
Field rules:
cluster_id:PRODUCT-ATTRIBUTE-NUMBER, e.g.PAL-HYG-001. Once assigned, an ID is never reused — not even after the page is retired.status:active(under governance) /watching/frozen(weaker site frozen) /stale(no review in 6 months, forced onto the agenda).allowed_scope: write "X allowed; Y not allowed," never just a prohibition. Rules that are too rigid get routed around.inquiries_6m: qualified inquiries from that primary page over six months, filled in by sales, not by SEO.
Register informational clusters too, like the third row — they are the type every site duplicates.
Start with 10 rows. Once you can maintain 10, grow to 50. A 500-row table on day one maintains zero rows.
B. Page merge 301 checklist
Before shipping:
[ ] 12 months of GSC data exported and archived for both pages
[ ] GA4 landing page + key event data archived for both pages
[ ] HTML snapshot of the weak page saved
[ ] Backlink list for the weak page exported
[ ] Unique content on the weak page (specs/FAQ/images/cases) re-edited into the strong page
[ ] Site-wide internal links to the weak page repointed directly at the strong page
[ ] 301/308 rule written (server-side, not meta refresh, not JS)
[ ] No A→B→C redirect chain
[ ] Weak URL removed from the sitemap; strong page keeps a self-referencing canonical
[ ] Structured data merged into the strong page
After shipping:
[ ] curl -I against the real domain returns 301 with the correct Location
[ ] Verified on both mobile and desktop
[ ] Updated sitemap submitted in GSC
[ ] Crawling, indexing, impressions and clicks for both URLs recorded at weeks 1, 2, 4, 8
[ ] Landing-page key events and sales feedback tracked alongside
[ ] The 301 rule added to the annual review list, default action: keep
The first four items are your rollback basis. A merge without baseline data can neither be judged nor undone. The last item matches the official floor quoted in the main post: keep redirects "generally at least 1 year," and deleting one requires a written reason.
C. Cross-site conflict log
Conflict ID:
Cluster ID:
Pages involved: site A/URL, site B/URL
6-month data per page: impressions / clicks / avg position / qualified inquiries
Decision tree node hit: Q__
Verdict: keep both / differentiate / merge + 301 / freeze and observe
Basis (one sentence):
Arbiter:
Date decided:
Review date:
This is the template most likely to be skipped and the one that least deserves it. An undocumented verdict cannot become precedent, and the next conflict of the same kind gets argued from scratch.
Boundaries
The roles, the SLA, the scoring, and the 30-day cadence in this post are all [FRAMEWORK] — a default starting point you can use directly, and a set of assumptions your data is allowed to overturn. Check whether they hold in your organization before adopting them.
The companies, sites, and numbers in the tables continue the fictional case from the main post. They represent no real client and constitute no promise of results. I do not hold real GSC/GA4/CRM data for any company's dozen sites, and I have no "federated governance grew X%" conclusion — so none of that appears here.
The reasoning, the official sources, and the full argument are in the main post: Multi-Site SEO Governance: Clusters to 301s.
Comments
Comments are powered by GitHub Discussions. Sign in with GitHub to comment. Open the matching Discussion