The checklist at a glance

Step 1 · List every URL that matters (before touching the CMS)

• Get Google Search Console access.Ask the client to add ash@nickgray.net as a Full user. GSC is the most important source: it shows which pages actually get clicks and links.
• Export from GSC: Performance → Pages (last 16 months), Indexing → Pages (indexed and not indexed), and Links → Top linked pages.The pages with clicks and outside links are the ones that cost rankings if they break.
• Grab the old sitemap (/sitemap.xml or /sitemap_index.xml).The full list of what the old site says it has.
• Take a backlink snapshot. Ask Claude for /vs3-backlink-snapshot.Keeps a record of which URLs other sites link to.
• Crawl the live site.Catches pages that are linked but missing from the sitemap.
• Copy the old site's existing redirects.We have to keep these. WordPress: Redirection plugin, Yoast Premium, Rank Math or .htaccess. Webflow: Site settings → Publishing → 301 redirects. Substack has none.
• Merge it all into one master URL sheet, remove duplicates, sort by clicks + backlinks.Columns: old_url · type (post / page / category / tag / author / media / other) · GSC clicks · backlinks · new_url · action (same slug / 301 / drop) · migrated? · verified?. The top 20–50 rows get checked by hand after launch.

Step 2 · Map each old URL to a new one

• Keep the same slug wherever possible.Posts and pages both live at the root, /{slug}/, not under /blog/. See How our URLs work below.
• Give every URL whose shape can't exist here its own 301.Example: /2019/05/my-post/ or /p/my-post → /my-post. There are no wildcard rules, so it's one row per old URL. Use the platform cheat sheets below.
• Fill new_url and action for every row.Anything with traffic or backlinks gets "same slug" or "301", never "drop".
• Check for slug clashes between pages and posts.If a page and a post share a slug, the page wins and the post disappears.
• Substack only: was it on the client's own domain?If it lived on name.substack.com, we can't redirect it. Tell the client and have them link the new site from their Substack about page and last post. Also agree before cutover what happens to the newsletter.

Step 3 · Move the posts (top priority)

For every post, carry over:

• Title and slug, exactly.Slug comes from the URL sheet. A changed slug is a broken URL.
• Full body: headings, lists, bold/italic, quotes, tables, and embeds (YouTube, Vimeo, tweets, Spotify, podcasts, Instagram).
• Original publish date.Never let it default to today. Google and readers both rely on dates.
• Cover image, excerpt and categories.
• SEO title and meta description, plus the social (OG) image if it differs from the cover.Pull them from Yoast / Rank Math, Webflow SEO settings, or Substack's SEO fields.
• Noindex stays noindex.If a page was hidden from Google on the old site, keep it hidden.
• Ask the client about drafts and paywalled posts.Drafts are left out by default. Paywalled Substack posts export with the full text, so the client decides whether they go public.

For whoever runs the import: posts with images or quotes go in with pw create (Lexical upload nodes), because pw article publish rejects them. --publish-at schedules an import. After any pw patch, run pw deploy <slug>, because patching doesn't deploy on its own.

Step 4 · Move the photos & files (top priority)

• Download every image at full resolution, not the resized thumbnails.WordPress: the originals in /wp-content/uploads/ (drop the -300x200 size endings). Webflow: the website-files CDN. Substack: substackcdn.com. Webflow images can vanish once the client cancels, so download them first.
• Upload them to our media and point every reference at our copy.Nothing in the content may still load from the old domain or CDN.
• Alt text, captions and photo credits come across.Where alt text is missing, ask Claude for /vs3-alt-text.
• Downloadable files: PDFs, lead magnets, slide decks.These often have backlinks. Check them in GSC.
• Logo, favicon, headshots, hero image.Neon and marquee themes fall back to the logo as the hero background when there's no hero image.
• Image URLs that rank in Google Images or have backlinks get a 301 to the new media URL.
• No oversized photos.Body photos are capped at 700px. Check with /seo-images or PageSpeed.

Step 5 · Inventory everything else (go through it with the client)

This is the list that's easy to miss.

Site structure

• All static pages: About, Contact, Speaking, Media/Press, Work With Me, Now, Books, Podcast, Testimonials.
• Header and footer navigation, in the same order.
• Footer content and legal pages: copyright, social links, Privacy, Terms, Disclaimer, affiliate disclosure.
• Pages the client wants retired.Write them down. They still get a 301.

SEO

• Meta titles and descriptions on pages too, not only posts.
• Schema (Person, Organization, Book, Podcast).Rebuild it through the tenant fields / extraJsonLd.
• Canonical tags that point elsewhere (cross-posted content) and any robots.txt customisations.
• Internal links inside posts point to the new paths.Rewrite /blog/x, /p/x, /2019/05/x links directly. Don't rely on redirects for our own links.

Domain, DNS & email (where most migrations break)

• Export all the client's current DNS records before switching nameservers: MX, SPF/DKIM/DMARC, CNAMEs for email tools, Calendly, etc.Re-create them with pw dns, or the client's email stops working.
• Keep the Search Console verification TXT record.If it's lost in the move, the client loses GSC access.
• Run pw domain add first, then send the nameserver pair it returns.Cloudflare can assign a different pair per domain, so never send a pair from memory. See Domains & DNS.
• Note who holds the registrar login (client or us).

Tracking & integrations

• Analytics and tags (optional): GA4, Google Tag Manager, Meta Pixel, LinkedIn Insight, etc.Not every client has these. Only carry over what the old site already uses, and add it with our deferred-loading pattern so it doesn't slow the site. We confirm it works after launch (step 8).
• Newsletter signup form: which provider (ConvertKit, Mailchimp, Beehiiv, Substack) and the form embed code.We only connect their existing form to the new site. The client keeps managing their list and newsletter in their own tool, so we don't export or move subscribers.
• Contact form destination, booking widgets (Calendly, SavvyCal), payment and affiliate links, and any custom header/footer code.

Facts

• Run /fact-check on the bio, About page and any claims before the site goes live.

Step 6 · Pre-launch checks (on the preview URL)

• Post count matches the old site, minus any agreed drops.
• Every row in the URL sheet has a new_url and an action.
• Nothing still points to the old domain or CDN.Search the content export: pw content-export <slug>.
• No slug clashes between pages and posts.
• All redirects are created (pw get redirects), and none lead to a 404 or chain through another redirect.
• Top 20 posts compared side by side with the old site: images, embeds, formatting, dates.
• Key pages checked on mobile.
• WordPress sites: run /vs3-migration-diff <slug>.It diffs the URLs, tests the redirects, checks that images load, and recovers images at risk.

Step 7 · Cutover

• Agree the date and time with the client (Manila time).
• Content freeze.Anything the client publishes on the old site after the export has to be migrated too, so ask them to stop posting there.
• Switch the domain, then re-create the DNS records from step 5. Ask Claude to "add a custom domain".Nameserver mode is the default. A site that hasn't changed within about 3 minutes of a build is normal.
• Keep the old site reachable for at least 30 days (WordPress: at old.<domain>).It's the fallback and the image source if anything was missed. The client must not cancel it yet.

Step 8 · Verify on the live site (the live site is the truth)

Same day

• Every URL in the sheet returns a 200, or one 301 that lands on a 200.Script it over the sheet and fill in the verified? column.
• Top 20–50 traffic URLs checked by hand.
• www redirects to the main domain.
• Email still works.Send a test to the client's address.
• Plausible is recording pageviews, and the client's own analytics and pixels (if they have any) are firing.This is where tracking gets confirmed, after launch, once real traffic hits the new site.
• Forms submit (including the newsletter signup), and /sitemap.xml lists the new URLs.
• The launch gate is passed: GSC, Plausible, Bing + IndexNow.

In Search Console

• Submit the new sitemap.
• Request indexing (URL Inspection) on the top 10–20 pages.
• No "Change of Address" needed when the domain stays the same.Only use it if the domain itself changed.

Days 3, 14 and 30

• Watch GSC → Indexing → Pages for "Not found (404)" spikes.Add a redirect for anything that shows up.
• Compare GSC clicks and impressions with the pre-migration baseline.A small dip in weeks 1–2 is normal. A drop that stays on specific URLs means a bad redirect.
• Run /audit <slug>, then /vs3-seo-audit.
• Day 30 with no issues: the client can shut down the old platform.

Step 9 · Hand over & log it

• Comment on the client's Trello card (Nick + Pau board): what moved, how many redirects, anything dropped, follow-ups.
• Save the client's standing preferences in the CLAUDE.md at the root of their site-* repo.
• Store the master URL sheet with the client's files.It's the record that nothing was lost.

Reference · How our URLs work

Plan every redirect around these rules.

Redirects: matching ignores capitals and trailing slashes. Chains get flattened automatically and loops are rejected. Saving one rebuilds the site. The target can be a path or a full URL. No wildcards, so every old URL needs its own row. Use pw for everything, never raw REST or curl.

Reference · Platform cheat sheets

Site Launch

Hi [Name],

The domain now lives under the site we've built! You can view it here → [site URL]

Please disregard any email notification you might receive about a published article on your site while we finish polishing things up.

If there's anything you'd like changed or updated, let us know and we'll work on it.

Hi [Name],

Now that we've finalized the site and it's ready to go live, we need your help pointing your domain to the site we built. Please update the nameservers on your registrar (I believe that's [registrar, e.g. GoDaddy]) to these two:

- nia.ns.cloudflare.com
- vasilii.ns.cloudflare.com

We've already pulled in your existing DNS records, so email and anything else pointed at the domain will keep working through the switch. If you need a hand, book a call with Pau here → https://cal.com/team-nick-pau/10min

Thank you!

Cancellation

Hi [Name],

Thank you so much for letting us know; it has been great working with you.

Are you planning to host the site on your end? If so, we're happy to keep hosting it for one more month for free so you have time to get set up and confirm the site is live on your end before switching nameservers/DNS. If not, we're happy to take the site down right away.

We've also attached the ZIP file containing all your posts, pages, and media. Please note that the themes are not included in the export.

If there's anything else you need help with, just let us know.

Sales & Calls

Hi [Name],

Here's how to get into your site's backend:

Login page: [admin URL]
Email: [client email]

We don't send passwords by email. Click "Forgot password" on the login page and it'll send you a reset link directly.

Let us know if you get stuck.

Hi [Name],

Time for our regular check-in! Grab a slot that works for you here:

[booking link]

A few things to think about before we chat:
- Any updates, wins, or new content ideas since we last spoke
- Anything on the site you'd like changed

See you soon!

Hi! Thanks for the call today. I enjoyed our chat.

Please send me the following just like we discussed on the phone:

I'll circle back once everything is completed.

Hi,

Just wanted to follow up as it looks like we missed each other on our scheduled call today.

I totally understand today might have gotten busy: it happens. At your earliest convenience, you can grab a new time that works best for you here:

[your booking link: see the Calendar Links in Resources]

Looking forward to chatting whenever it's convenient for you.

After the client says it's done, check:

• Both nameservers resolve on the domain (registrar lookup or dig NS <domain>).
• Existing DNS records survived, especially MX/email. This is why we pull them in first, but confirm it actually held.
• SSL certificate issued and the site loads on the client's own domain, not just the personalwebsites.org staging URL.
• Launch gate passed: GSC, Plausible, Bing (see Onboarding) before sending the Live Site email.

Backup path · Cloudflare account access

Need a hand

Active Discount Codes

Pulled from Stripe coupon screenshots in the doc: all fixed amounts off, applied once, against the one-time setup fee. Stripe's internal promo_… API IDs and live redemption counts are left off this page; check Stripe directly before relying on redemption limits.

The 12 themes

Backend Access

Calendar Links

Client-Facing Guides

Content Rules

Content

Already Automated

These already run through Claude, so ask for them instead of redoing them by hand.

Not the full list. There are 47 of these skills. Ask "what can you automate for X" if what you need isn't above.

Affiliate Program