The Rebuild Specification

How the site would be rebuilt and migrated — specified in full, deliberately not executed, so the decision can be made later with everything already worked out.

Movement IV. Status: specified, not executed. This document records how the rebuild and migration would be carried out, so that the decision can be made later with full information and so that nobody has to re-derive any of it. Nothing described here has been performed. Deliberate decision, 2026‑08‑04: the site will be rebuilt correctly at a future date rather than hurriedly now.

Every statement of current state below was measured on 2026‑08‑04 and the source artifact is named. Every statement about the target is a proposal.

Contents

• 1. Why this is written down and not done
• 2. Current state of record
• 3. Target architecture
• 4. The URL and redirect map
• 5. M1 — Build
• 6. M2 — Instrument
• 7. M3 — Cutover
• 8. Acceptance criteria
• 9. Risks and rollback
• 10. Explicitly out of scope
• 11. Decisions required before M1 starts

1. Why this is written down and not done

Three reasons, in order of weight.

A migration is the single riskiest routine operation in SEO. It puts every existing ranking, backlink and citation at risk in one moment. The correct time to perform one is when there is instrumentation to detect a regression and a stable baseline to compare against. Right now there is neither: no analytics exist (§2), so a post-migration traffic collapse would be invisible.

There is currently almost nothing to lose, which is an argument for care, not haste. The site ranks for zero keywords and has zero AI-assistant mentions. That means a migration cannot destroy rankings — but it also means there is no deadline. The pressure to move fast is imaginary.

Everything valuable can start without it. Per S18.8, items 1–6 of the fix list are improvements to the existing Webflow site and can begin immediately. Only item 7 — the platform change — requires this document.

The sequence that follows from that: instrument first, publish for a quarter, then migrate with a real baseline and real evidence of what matters.

2. Current state of record

Verified 2026‑08‑04. Sources: raw/stack.json, raw/psi_*.json, raw/danielle_onpage_*.json, raw/sitemap_urls.json.

2.1 Platform and network path

2.2 Application capability

2.3 Performance baseline (mobile Lighthouse)

This table is the before measurement. Any rebuild is judged against it.

Desktop home: performance 94, LCP 1.5 s. Accessibility across pages: 80–89. SEO: 100 everywhere. Root-document server response: 0 ms (already edge-cached).

3. Target architecture

The governing constraint is S18.7: the strategy requires publishing many pages cheaply. Any target that keeps page creation a designer task fails regardless of its other merits.

3.1 Proposed stack

Alternative worth pricing if she prefers a visual editor: keep a CMS but choose one with a real content API and collection templates. The non-negotiable is templated content types plus clean export — not any particular vendor.

3.2 Performance budget

Enforced on every deploy; nothing ships that breaches it.

The weight budget is the load-bearing one. A page of text, images and a booking button has no legitimate reason to exceed it.

3.3 Booking and back end

The flow to replace the four-to-eight manual touches described in S18.4:

CTA "Book a call"
  → live availability (scheduler)
  → slot selected → confirmation email + calendar invite (automatic)
  → intake questions asked AFTER the slot is held
  → reminder at 24 h and 1 h
  → contact created in CRM, tagged by source
  → post-call: proposal / Stripe checkout link for the relevant rung

Tooling options, all adequate — the choice belongs to Danielle (§11):

• Calendly / Cal.com / SavvyCal — scheduling only. Simplest, cheapest, fastest to install.
• Practice Better / SimplePractice — scheduling plus clinical notes, intake and billing in one system. Heavier, but if she wants notes and invoicing in the same place, this collapses several tools into one.

Design rule regardless of choice: the intake questions currently on /contact are asked after the booking is secured. A held slot with three unanswered questions beats a perfect intake form nobody submitted.

4. The URL and redirect map

All eight live URLs, from raw/sitemap_urls.json. Every one keeps its path. There is no reason to change a URL during a platform migration, and every reason not to — changing platform and changing URLs at the same time makes any regression impossible to diagnose.

Additional redirect rules required at cutover:

• http:// → https:// — single hop, direct to the canonical host. Fixes the current double redirect.
• Apex → www (or the reverse — see §11; the decision is arbitrary, but it must be made once and never revisited).
• Any new content lives on new paths (/articles/*, /podcast/<episode-slug>) and therefore needs no redirects.

5. M1 — Build

Built in parallel with the live site. Nothing public changes during M1.

1. Stand up the generator; deploy to a preview host (preview.<something>.pages.dev), noindex throughout.
2. Port all 8 pages, preserving copy verbatim unless Danielle approves a change. Content moves into Markdown.
3. Rebuild the design to the performance budget of 3.2 — same look, a fraction of the bytes.
4. Build the four content templates. Prove the article template by rendering three real pieces from the S6 content plan.
5. Build the episode template and port the podcast back-catalogue — the maineshaman.com pattern from Movement III, transcripts included. This is the largest single content win available and it needs the rebuild to exist.
6. Structured data throughout: Person, Service, FAQPage, PodcastEpisode.
7. Canonicals on every page.
8. Accessibility to 100 — audited, not assumed.
9. Wire forms to the ESP and CRM; wire the scheduler; wire Stripe for the S16 rungs.

6. M2 — Instrument

M2 does not wait for M1. It is performed on the existing Webflow site, immediately, and is the prerequisite for judging the migration at all.

1. GA4 installed on the live Webflow site.
2. Search Console verified, sitemap submitted.
3. Baseline recorded and frozen: traffic, queries, impressions, Core Web Vitals field data — a minimum of one full quarter before cutover.
4. The same property and measurement IDs carry to the new site, so the series is continuous across the migration rather than restarting at zero.

This ordering is the point of the whole document. Migrating first and instrumenting afterwards means never knowing whether the migration helped or hurt.

7. M3 — Cutover

The only user-gated step in this specification. It requires Danielle's explicit go-ahead on the day, and it does not begin without it.

Pre-flight, all of which must pass before anything is switched:

1. Acceptance criteria (§8) green on the preview host.
2. Full crawl of the preview site — zero broken links, zero missing pages against the §4 map.
3. DNS TTLs lowered to 300 s at least 24 hours ahead.
4. Rollback rehearsed: the exact records needed to restore Webflow, written down and ready to paste.
5. A quiet window chosen — not mid-launch, not during a campaign.

Cutover:

6. Move DNS to Cloudflare; point at Pages.
7. Remove noindex.
8. Verify from an external resolver and Danielle's own — not just from one machine.
9. Submit the new sitemap; request re-crawl of the eight URLs.
10. Watch Search Console daily for 14 days. Any indexing drop is investigated the same day.
11. Keep the Webflow subscription active for at least 30 days after cutover. It is the rollback.

8. Acceptance criteria

The rebuild is done when an executable check passes — not when it looks finished. Per house rule, the check is written before the build and ships with it.

Criterion 11 exists because the most common silent failure in a migration is copy quietly altered in the port.

9. Risks and rollback

Rollback: restore the Webflow DNS records (documented in §2.1 and kept ready per §7.4) and the old site is live again within one TTL. The Webflow subscription stays active 30 days precisely so this remains possible.

10. Explicitly out of scope

Named so nobody assumes them later:

• Any change to daniellecarron.com has not been made. Nothing in this document has been executed.
• No visual redesign. The look is good (S18.1); the target reproduces it at a fraction of the weight.
• No copy rewrite as part of the migration. Copy changes are a content decision, made separately, never bundled into a platform change.
• No new offers. The S16 ladder is a business decision that precedes its implementation here.
• No membership, course platform or community software.

11. Decisions required before M1 starts

None of these are urgent. All of them are Danielle's.

1. Scheduler — lightweight (Calendly / Cal.com / SavvyCal) or full practice-management (Practice Better / SimplePractice)? Depends on whether she wants clinical notes and billing in the same system.
2. ESP — the S12 tribe island needs one. Choose before M2 so the list starts accumulating immediately, on the existing site.
3. Canonical host — www or apex. Arbitrary, but decided once and never revisited.
4. Visual editing — does she need to edit pages herself without a developer? If yes, the generator choice changes.
5. Podcast transcripts — the back-catalogue port is the largest content win available (Movement III, maineshaman.com). Does she want all 66+ episodes, or the best twenty first?
6. Timing — the recommendation is one full quarter of M2 instrumentation and publishing before M3 cutover.