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. Specified, not executed. The plan, ready for when you want it. Current-state numbers were measured 2026‑08‑04; everything 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 map — every path stays
• 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 riskiest routine operation in SEO, putting every ranking, backlink and citation at risk in one moment. Do one only when you can detect a regression against a stable baseline. Right now you can't: no analytics exist (§2), so a traffic collapse after the move would be invisible.

You have almost nothing to lose today, which argues for care, not haste. The site ranks for zero keywords and has zero AI-assistant mentions. A migration can't destroy rankings you don't have, and there's no deadline.

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

So: instrument first, publish for a quarter, then migrate against a real baseline. Until you say go, this plan stays specified, not executed.

2. Current state of record

Measured 2026‑08‑04 (raw/stack.json, raw/psi_*.json, raw/danielle_onpage_*.json, raw/sitemap_urls.json).

2.1 Platform and network path

Three terms: the CMS is the software you edit your site in (yours is Webflow). DNS is the internet's address book, pointing your domain at the machine that serves it. The edge, or CDN, is servers near your visitors keeping copies of your pages so they load fast.

2.2 Application capability

Structured data is machine-readable labelling telling search engines what a page is (a person, a service, an episode). A canonical tag names a page's one official address.

2.3 Performance baseline (mobile Lighthouse)

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 needs many pages published cheaply. Any target that keeps page creation a designer's task fails.

3.1 Proposed stack

If visual editing matters to you, price an alternative: a CMS with a real content API and collection templates. The non-negotiable is templated types plus clean export, not any 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 reason to exceed it.

3.3 Booking and back end

The flow replacing the four-to-eight manual touches 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

Options, all adequate. The choice is yours (§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 collapses several tools into one if you want notes and invoicing together.

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

4. The URL map — every path stays

All eight live URLs, from raw/sitemap_urls.json. Every one keeps its path, so none needs a redirect. This is a rehost, not a restructure: the same address serves the same page from a different machine, so your three real inbound links keep working untouched.

Changing platform and URLs at once would make any regression impossible to diagnose.

The only redirects anywhere are host-level, deciding which address is official; no page moves:

• http:// → https:// in a single hop, direct to the canonical host. The one genuine improvement: today it takes two hops.
• Apex → www, or the reverse (§11). Arbitrary, but made once and never revisited.
• New content lives on new paths (/articles/*, /podcast/<episode-slug>); no history, 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, copy verbatim unless you approve a change. Content moves into Markdown.
3. Rebuild the design to the 3.2 budget: 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). The largest single content win, 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 (email service provider) and CRM; wire the scheduler; wire Stripe for the S16 rungs.

6. M2 — Instrument

M2 doesn't wait for M1. It happens on the existing Webflow site, immediately.

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, for a minimum of one full quarter before cutover.
4. The same property and measurement IDs carry to the new site, so the series stays continuous.

Migrate first and instrument after, and you'll never know whether the move helped or hurt.

7. M3 — Cutover

The only step that waits on you: it doesn't begin without your explicit go-ahead on the day.

Pre-flight, all of which must pass:

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 to restore Webflow, written down, 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 your own machine.
9. Submit the new sitemap; request re-crawl of the eight URLs.
10. Watch Search Console daily for 14 days; investigate any indexing drop the same day.
11. Keep the Webflow subscription active for at least 30 days after cutover. It is the rollback.

8. Acceptance criteria

Done means an executable check passes, not that it looks finished. Each check is written before the build and ships with it.

Criterion 11: the most common silent migration failure is copy quietly altered in the port.

9. Risks and rollback

Rollback: restore the Webflow DNS records (§2.1, kept ready per §7.4) and the old site is live within one TTL.

10. Explicitly out of scope

So nobody assumes them later:

• No change to daniellecarron.com has 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. Copy changes are a separate content decision, 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 are yours.

1. Scheduler: lightweight (Calendly / Cal.com / SavvyCal) or full practice-management (Practice Better / SimplePractice)?
2. ESP: the S12 tribe island needs one. Choose before M2 so the list starts accumulating on the existing site.
3. Canonical host: www or apex. Arbitrary, but decided once and never revisited.
4. Visual editing: do you need to edit pages yourself? If yes, the generator choice changes.
5. Podcast transcripts: the back-catalogue port is the largest content win (Movement III, maineshaman.com). All 66+ episodes, or the best twenty first?
6. Timing: one full quarter of M2 instrumentation and publishing before M3 cutover.