Phase plan — webhook-architecture.com

The schedule to grow this site phase-by-phase, generated from the Django Site model. No OpenRouter / no API — you (Claude Code) do the work, grounded in the real markdown under content/.

Niche: Webhook Architecture & Event-Driven Integration
Audience: Backend engineers, integration specialists, SaaS founders, API developers
Live now: 54 pages, 91,513 words
Current phase: expansion
Next phase to build: maturity

How to upgrade a phase

Work through every step in order. Do not skip the uplift, the term cleanup, the SVG render check, or the finish/deploy steps — those were the gaps in earlier runs.

Read & orient. Read this whole file, then skim content/ to learn what exists and the writing tone.
Uplift EVERY existing page (not just new ones). Bring all current pages — from earlier phases — up to the Page blueprint below: its page anatomy, frontmatter, JSON-LD schema, the custom SVG visuals, and the mandatory wiki-style interlinking. Old pages must reach the current standard, not be left as they were.
Build the next phase. Add this phase’s page mix (see schedule), slotting pages into the existing hierarchy, each built to the same blueprint standard.
Keep it niche-specific. Section topics must be drawn from this niche, not generic placeholders.
Remove internal IA/SEO terms from visible copy. The words pillar, cluster, long-tail (and “hub and spoke”, “supporting page”, etc.) are internal labels — they must not appear in reader-facing prose. Scan and fix:
```
python3 /home/martin/WebstormProjects/_qa/term_lint.py webhook-architecture.com
```
(Legit domain uses of “cluster” — e.g. a Kafka/DB cluster — are fine; rewrite only the information-architecture sense.)
Author custom SVG visuals per the “Custom visuals” section, then build the site and verify the SVGs render correctly ON THE PAGE — the page’s CSS/typography must not leak in and break them. Fix and rebuild until clean:
```
cd /home/martin/WebstormProjects/webhook-architecture.com && npm run build
python3 /home/martin/WebstormProjects/_qa/svg_check.py webhook-architecture.com
```
It statically validates each SVG (XML, id refs), then renders the BUILT pages in headless chromium with the real stylesheet applied — flagging page typography overflowing labels, distorted/zero-size, and empty SVGs. Must pass with no FAILs.
Record completion (updates page/word count, advances current→next phase, and rewrites this plan ready for the next phase). From the Django project (/home/martin/PycharmProjects/Django-Pillar-Cluster-Long-Tail):
```
.venv/bin/python manage.py finish_phase webhook-architecture.com --completed maturity \
    --blueprint "/home/martin/WebstormProjects/webhook-architecture.com/_plan/blueprint.json"
```

Commit & deploy. Build, deploy to Cloudflare, and push to GitHub:

cd /home/martin/WebstormProjects/webhook-architecture.com
npm run deploy          # build + wrangler deploy (auth from the site .env)
git add -A && git commit -m "Upgrade to maturity phase" && git push

Phase schedule

#	Phase	Status	Adds	Target total	Focus
1	1. Foundation	✅ done	2-3 pillars + 10-14 clusters + 8-12 long-tails	~22	Establish core authority: the main pillars and their primary clusters, with enough long-tails to validate demand. Get a consistent page skeleton in place.
2	2. Expansion	✅ done	1-2 pillars + 7-10 clusters + 18-25 long-tails	~50	Broaden coverage: fill out each pillar’s clusters and add the high-intent long-tails around them. Strengthen interlinking between siblings.
3	3. Maturity	➡️ NEXT	4-6 clusters + 28-40 long-tails	~82	Deepen the long tail: comprehensive how-tos, comparisons and edge-case pages under existing clusters. Ensure FAQ blocks and schema on every page.
4	4. Authority	… future	2-3 clusters + 20-30 long-tails	~105	Complete topical authority: remaining gaps, advanced/expert pages, and a tight internal link graph so every page is 1-2 clicks from its pillar.

Priorities for the next phase (maturity)

Fill the webhook-security-signing-validation pillar: it has only 4 cluster children (hmac-signature-verification, jwt-based-webhook-auth, key-rotation-strategies, replay-attack-prevention) but no long-tail pages under any of them yet — add 2 long-tails per cluster first
Add a monitoring/observability cluster under webhook-architecture-fundamentals-design-patterns covering OpenTelemetry instrumentation, SLO definition, and delivery failure alerting — currently absent despite being referenced in the pillar
Add comparison/decision long-tail pages (e.g. ‘HMAC-SHA256 vs RSA asymmetric webhook signatures’, ‘at-least-once vs exactly-once delivery trade-offs’) to help engineers make architectural choices — a high-intent gap
Expand resilient-delivery-retry-strategies with a circuit-breaker long-tail covering per-endpoint breaker state machines, which is referenced in the pillar but has no implementation detail page

Page blueprint

(tailored to this site)

Frontmatter (every page): title, description, slug, type, breadcrumb, datePublished, dateModified
Schema (JSON-LD): Article, TechArticle, BreadcrumbList, HowTo
Interlinking: Every page must inline-link the first mention of any concept that has its own page, woven naturally into the prose — not appended as footnotes. Examples for this niche: ‘configure exponential backoff with jitter to cap retry storms’, ‘validate signatures via HMAC-SHA256 verification’, ‘route undeliverable events to a dead-letter queue’. Each page also ends with a ‘Related’ block (3-5 peer/child links) and an up-link to the parent pillar or cluster in the opening paragraph. Cluster pages must link back to their pillar in the first sentence. Long-tail pages must link to their cluster and at least two sibling long-tail pages.

pillar pages (~4500 words)

Lead paragraph: define the pillar’s problem domain and scope; inline up-link to site home; state who this guide is for (backend engineers, integration architects)
Architecture overview: high-level lifecycle diagram described in prose, covering all sub-topics in this pillar
Core concept section 1 (e.g. delivery models / transport semantics): conceptual explanation with key trade-offs
Core concept section 2 (e.g. schema contracts / security model): design decisions and constraints
Core concept section 3 (e.g. resilience patterns / observability): system-level considerations
Production implementation checklist: HowTo-structured numbered steps with inline cross-links to cluster pages
Failure mode reference table: failure mode | impact | mitigation, covering 4-6 modes specific to this pillar
Runnable code example: complete, annotated snippet (Python or TypeScript) demonstrating the pillar’s central pattern
Operational considerations: monitoring signals, SLO definitions, alerting thresholds relevant to this pillar
Related block: 4-6 links to cluster pages under this pillar plus 1-2 cross-pillar links

cluster pages (~3500 words)

Lead paragraph: narrow problem statement; inline up-link to parent pillar; state reader prerequisite knowledge
Core implementation patterns: 2-4 named patterns specific to this cluster topic, each with rationale and trade-offs
Security controls and validation: threat model and defense-in-depth steps relevant to this cluster topic
Operational workflows and CI/CD integration: how this cluster topic fits into deployment pipelines and automation
Failure mode analysis table: failure mode | impact | mitigation (4-6 rows specific to this cluster)
Runnable implementation example: complete, production-ready code snippet with inline comments explaining non-obvious decisions
Debugging checklist: markdown checklist of concrete diagnostic steps for common failure scenarios
Related block: 2-3 sibling cluster links + 1-2 long-tail child links + up-link to pillar

long_tail pages (~2000 words)

Lead paragraph: precise problem framing (one specific scenario); inline up-link to parent cluster and cross-link to one related sibling
Prerequisites: explicit list of configs, libraries, or concepts the reader must have in place before implementing
Step-by-step implementation: numbered steps with runnable code at each critical step; no hand-waving
Verification and testing: how to confirm correct behaviour (unit test pattern, curl command, or log assertion)
Failure modes and gotchas: 2-4 specific pitfalls with concrete remediation for this exact scenario
Related block: 2-3 sibling long-tail links + up-link to cluster

All code examples should use Python or TypeScript consistently within a page; prefer TypeScript for schema/validation topics and Python for delivery/retry topics to match existing content conventions. Every table must have a header row and at least 4 data rows to be substantive. HowTo JSON-LD steps must match the production implementation checklist section exactly. TechArticle proficiencyLevel should be ‘Expert’ for pillar and cluster pages, ‘Intermediate’ for long-tail pages. Avoid generic section titles like ‘Introduction’ or ‘Conclusion’ — every heading must name the specific technical concept it covers.

When upgrading or building any page, add a custom, hand-authored inline SVG wherever a visual would genuinely raise quality (architecture/data-flow diagrams, sequence or state diagrams, comparison matrices, timelines, annotated illustrations). Do NOT add decorative or generic stock-style images. Each SVG must: be original and specific to the page’s content; match the site’s existing design system (colours, fonts, stroke weight); be responsive (viewBox, no fixed pixel width) and accessible (/<desc>, role=“img”, aria-label); and use currentColor / CSS variables so it adapts to light/dark themes. Prefer one strong diagram that explains the hardest concept on the page over many small ones. Pillar pages should almost always carry a top-level overview diagram.</p>