Module 04 · Lesson 4 of 4
Content Architecture, Freshness and Internal Links
Content work does not end at publication. Pages live in a structure, compete for the same queries, and age at different speeds. Architecture decides how they support each other; freshness decides whether they stay true. This lesson closes the loop that Module 3's log opened: measurement told you what to build, architecture keeps it working.
Hubs and clusters, applied
You met the pattern in lesson 1.4; here it is with content. For each topic you compete on: one hub page that owns the head query and links to every cluster page; cluster pages that each own one specific query and link back to the hub and to one or two genuine siblings. Your Workbench 4.3 outline becomes a cluster page; the starred queries that share a theme share a hub. Two rules keep it clean: every cluster page has exactly one hub (competing hubs split the association), and no cluster page is published orphaned (lesson 1.4 applies to new content the moment it lands).
Freshness: honest versus fake
| Practice | Honest version | Fake version |
|---|---|---|
| Updated date | Changed because facts changed, date reflects the change | Date bumped, text untouched |
| Review pass | Checked claims, fixed what moved, noted what changed | "Reviewed" stamp with no diff |
| New data | This year's numbers replace last year's, method noted | Old numbers, new framing |
| Retirement | Outdated page merged into its hub, redirect in place | Dead page left live to decay |
Fake freshness is worse than none: it teaches readers (and systems) that your dates lie. AI search raises the stakes because generated answers favour current facts; a page whose dates are trusted is worth more than a page whose dates are decorative. Show a real last-reviewed date, and only change it when the content changed.
Update, merge, retire
The quarterly content pass, per page, asks one question: does this page still deserve its query? Update when the query is alive and the page is close (add the gain, fix the passages, refresh the facts). Merge when two of your pages compete for the same query (consolidate into the stronger URL and redirect the weaker). Retire when the query died or the page was never right for it (redirect to the nearest hub; a 404 or redirect costs less than maintaining a page that misleads). Your Module 3 log supplies the evidence: pages whose queries show AI answers with fresh competitors are the update queue; queries where you have two URLs and neither wins are the merge queue.
Cadence for AI search
AI search moves fast, so review frequency follows query volatility, not the calendar alone. Platform-behaviour pages (anything describing AI Overviews, AI Mode, assistants) deserve a check every month or two. Stable fundamentals (crawl mechanics, intent theory) need less. Tie the cadence to your run log: when a run shows an answer changed shape or a new source appeared on your queries, that cluster moves up the review queue.
- Hub: "AI SEO guide". Clusters: GEO explained, AI citations tracking, AI SEO tools.
- Log says the GEO page earns citations steadily; the tools page slipped when a competitor added live pricing.
- Decisions: GEO page, light freshness pass only. Tools page, update queue with a pricing-table gain. A fourth stray post "GEO tips 2024" competes with the GEO page: merge into it, redirect, and move its two decent internal links to point at the winner.
- List your pages for one topic. Draw the hub and clusters on paper, and mark any orphan or competing hub.
- Give every page one verdict: keep, update, merge or retire. Use the log, not gut feel.
- Execute the merges and redirects first; they are pure consolidation, no new writing.
- Set review dates per cluster by volatility, and put the first one in the calendar.
When is it legitimate to change a page's last-reviewed date?
Two of your pages both target one query. What is the fix?
How often should AI-search-related pages be reviewed?
Sources used in this lesson
Google Search Central: helpful, reliable, people-first content
Google Search Central: consolidating duplicate URLs