15 — Site Migration & Launch | Dr J's Binding Protocol

1. Migration Architecture Overview

We are replacing two WordPress/WooCommerce/Elementor sites with purpose-built static HTML + PHP sites. This is a full platform migration — not a theme change or CMS upgrade. Every URL structure, every asset path, and every server-side behavior changes.

Sites Being Migrated

Property	Patriot Chassis	The High Road Mfg
Domain	patriotchassis.com	thehighroadmanufacturing.com
Old platform	WordPress + WooCommerce + Elementor + Astra	WordPress + WooCommerce + Elementor + Astra + NitroPack
New platform	Custom HTML/CSS/JS + PHP API + MySQL	Custom HTML/CSS/JS + PHP API + MySQL
Old URL count	~197 (28 pages + 84 products + 14 categories + 67 tags + misc)	~145 (28 pages + 107 products + 9 categories + 1 post)
New URL count	103 (20 pages + 83 products)	~28 (12 pages + 16+ products + portal)
Product URL pattern	`/product/{slug}/` → `/product.php?p={slug}`	`/product/{slug}/` → `/product.php?slug={slug}`
Google indexed pages	~100+ (healthy indexing)	~3 (broken site, almost nothing indexed)
Social presence	Facebook, Instagram (1,381 followers)	Alignable only (no FB/IG found)
Migration risk	Medium — significant indexed content	Low — almost no SEO equity to preserve

Critical difference: Patriot Chassis has ~100+ indexed URLs, active backlinks from enthusiast forums (Pirate 4x4, Fuel Curve, Classic Broncos), and an active Instagram following. Every redirect matters. The High Road has almost no SEO equity — only 3 pages indexed, broken WooCommerce, 500 errors on product pages. THR migration is nearly a fresh start.

Migration Flow

DevHub (Build) Production (Live) ================== ==================== 1. Sites built & tested Old WordPress sites running on DevHub preview URLs at patriotchassis.com & thehighroadmanufacturing.com 2. 301 redirect map finalized & .htaccess rules written 3. DNS TTL lowered (T-7 to T-1) 4. SSL certs pre-provisioned Old server still live via DNS-01 challenge 5. devhub-deploy push ------> New files deployed to production docroot 6. .htaccess redirects active Old URLs redirect to new WordPress files removed New site serves all traffic 7. Post-launch monitoring Verify redirects, SSL, for 72 hours email, analytics 8. DNS TTL raised Old server decommissioned Old site archived after 30-day hold

Key principle: The old and new sites will share the same production server (prod-hetzner) and the same domain. This is a docroot swap, not a server migration. DNS records do not change. The dpanel nginx vhost continues to point at the same docroot — only the files inside it change.

2. Priority Matrix — Must Do vs. Clean Up After

Not everything has to be perfect on launch day. This section separates the hard blockers from the items that can be addressed in the days and weeks after go-live. Get the “Must Do” list to zero before deploying. Work through “Clean Up After” in the first 30 days.

20

Must Do Before Launch

16

Clean Up After Launch

⚠ Must Do Before Launch — Site Will Break Without These

Production .env files — DB credentials, Stripe keys, SITE_URL, MAIL_METHOD=sendmail, CORS_ORIGIN. Without this, nothing connects. §8 Pre-Launch
Purge all DevHub URLs from source files — search for devhub, preview.ecom.jj, devhub-mysql, devhub-mailhog. Any left behind will cause broken API calls, wrong CORS, or Google indexing DevHub URLs. §8 Pre-Launch
Product redirect pattern rule — RewriteRule ^product/([a-z0-9-]+)/?$ catches all ~84 PC products and ~107 THR products. Without this, every product page from the old site is a 404. §4, §5 Redirect Maps
Top page redirects — /products/→/shop.html, /about/→/about.html, /contact/→/contact.html, and the other high-traffic pages. These are the pages people have bookmarked and Google has indexed. §4, §5 Redirect Maps
Trailing slash normalization rule — WordPress uses trailing slashes on every URL. New site uses .html. Without the catch-all RewriteCond/RewriteRule, every bookmarked URL with a trailing slash 404s. §4 Redirect Maps
Production database provisioned with BOTH table tiers — Create the database and run ALL migrations. This creates two sets of tables: Hub tables (thr_*) for admin management AND Site tables (ths_*) for the live website. Verify with SHOW TABLES LIKE 'thr_%' and SHOW TABLES LIKE 'ths_%' — both must return results. Doc 10 §4
Product data pushed from Hub to Site tables — After migration, thr_products has data but ths_products is empty. Run the push (push.php?action=push-all or Portal deploy) to copy products from Hub → Site DB. Then run php api/generate-products-js.php to rebuild the JS data file. Without this step, the shop page will show zero products even though admin shows a full catalog. Doc 10 §4
.env has both DB_PREFIX and SITE_PREFIX — The production .env must define DB_PREFIX=thr_ (Hub tier) and SITE_PREFIX=ths_ (Site tier). If SITE_PREFIX is missing, config.php defaults to ths_, but relying on defaults is fragile. Make it explicit. Doc 10 §4
Stripe production keys in database — Switch from test keys to live keys in the settings table. Without this, checkout is broken. §8 Pre-Launch
Nginx vhost updated — PHP-FPM handler for .php files, custom 404 page directive. Without PHP handling, product pages and all API endpoints return raw PHP source code. §3 DNS & SSL
New robots.txt — Do NOT copy the old ones. Old THR has Disallow: /*? which blocks all product pages. Write fresh with only /admin/ and /api/admin/ blocked. §7 SEO
New sitemap.xml with production URLs — Must reference https://patriotchassis.com/ not DevHub. §7 SEO
Canonical tags use production domain — Every page has rel="canonical". If these point to DevHub, Google indexes DevHub instead of the real site. §7 SEO
CORS origin set to production domain — API calls from the frontend will be blocked by the browser if CORS is still set to the DevHub origin. §8 Pre-Launch
Email sending works — Contact form, order confirmations, and chassis request notifications must send via sendmail on production. Test before launch. §6 Email
404 page returns HTTP 404 — The custom 404 page must return a 404 status code, not 200. Verify via curl -I. §8 Pre-Launch
Forms submit successfully — Contact, chassis request, air ride request, full build. Test end-to-end including email delivery. §9 Launch Day
Old site files archived — Tarball of WordPress files + database dump BEFORE deploying new files. This is the rollback safety net. No archive = no deploy. §14 Archiving
Feeds updated with production URLs — Google Merchant XML and Facebook CSV currently contain DevHub preview URLs. Must reference https://patriotchassis.com/. §8 Pre-Launch
Admin auth strengthened — Current admin uses a simple token. Production needs something harder to guess at minimum. §8 Pre-Launch

✓ Clean Up After Launch — First 7–30 Days

Monitor access logs for missed 404s and add redirects — The redirect map covers known URLs, but real traffic will reveal edge cases. Parse access.log daily for the first week. §10 Post-Launch
WordPress infrastructure redirects — /wp-admin, /wp-content/, /wp-includes/, /wp-login.php. Low priority because no humans bookmark these, but bots and scrapers hit them. Add in Week 1. §4, §5 Redirect Maps
Tag page redirects (67 URLs) — All 67 /product-tag/ URLs are thin taxonomy pages with minimal SEO value. The pattern rule handles them, but these are low-value redirects. §4 Redirect Maps
Submit sitemap to Google Search Console — Do on launch day ideally, but the site works fine without it. Google will find the sitemap via robots.txt. §7 SEO
Submit sitemap to Bing Webmaster Tools — Lower priority than Google. Do in first week. §7 SEO
Request indexing on key pages via URL Inspection tool — Speeds up re-indexing but Google will crawl naturally. Nice to do on Day 1, not a blocker. §7 SEO
Update Google Business Profile — Verify website URL is correct. Create one for THR if it doesn’t exist. Do within 48 hours. §12 External Profiles
Update Facebook & Instagram profile links — Check bio links point to production URLs. Update within 48 hours. §12 External Profiles
Update Alignable listing (THR) — Low-traffic directory. Do in first week. §12 External Profiles
Install GA4 tracking — Important for measuring post-migration traffic, but the site functions without it. Ideally on Day 1, not a hard blocker. §13 Analytics
Set up uptime monitoring — UptimeRobot or similar. Do on launch day but not a pre-deploy requirement. §10 Post-Launch
Run Screaming Frog crawl for broken links — Full-site crawl to catch any broken internal links or images. Do Day 2–3. §10 Post-Launch
Update ad platform landing page URLs — If running Google/Facebook Ads, update landing pages. Old URLs redirect so ads won’t break, but direct links are better. First week. §13 Analytics
Update email signatures — Team email signatures with deep links to old URL patterns. First week. §12 External Profiles
Wayback Machine archiving of old site — Submit key pages to web.archive.org for permanent record. Nice to have, not time-sensitive. §14 Archiving
Decommission old WordPress database tables — After 30–90 days of stable operation, clean up old wp_* tables. No rush. §14 Archiving

Decision rule: If it causes a broken page, a 404 error for a real user, a security hole, or prevents a transaction from completing — it’s a Must Do. If the site works fine without it but it’s good practice — it’s Clean Up After.

3. Pre-Migration Audit & Benchmarks

Before touching production, capture baseline metrics. These benchmarks let you measure migration success and diagnose problems post-launch.

SEO Benchmarks to Record

Google Search Console: Export Performance data (clicks, impressions, CTR, position) for the last 12 months
Top landing pages: Sort by clicks, export the top 50 pages — these are the highest-priority redirect targets
Top keywords: Export all queries with position data — these must not be lost
Index Coverage: Screenshot the current indexed page count
Core Web Vitals: Screenshot current scores from Search Console
Backlink profile: Export from Ahrefs or Semrush (or use Google’s “Links” report in Search Console)
Structured data: Note all schema types currently in use (Product, Organization, BreadcrumbList)

Old Site Inventory — Patriot Chassis

Content Type	Count	URL Pattern	Notes
Pages	28	`/about/`, `/contact/`, etc.	Trailing slashes (WordPress default)
Products	~84	`/product/{slug}/`	WooCommerce pattern with trailing slash
Categories	14	`/product-category/{slug}/`	Including 3 sub-categories
Tags	67	`/product-tag/{slug}/`	Excessive — many are thin pages
Blog posts	1	`/hello-world/`	Default WP post, never replaced
Archives	1	`/2020/09/`	Monthly archive

Old Site Inventory — The High Road

Content Type	Count	URL Pattern	Notes
Pages	28	`/about/`, `/contact-the-high-road/`, etc.	Mix of real & junk pages
Products	107	`/product/{slug}/`	Many return 500 errors; mix of public & client invoices
Categories	9	`/product-category/{slug}/`	Organized by client name, not product type
Blog posts	1	`/hello-world/`	Default WP post

THR advantage: With only 3 pages indexed in Google and widespread 500 errors on the old site, the new THR site will almost certainly perform better from day one. Focus redirect effort on Patriot Chassis where real SEO equity exists.

Known External Backlinks — Patriot Chassis

Source	URL Linked	Priority
Pirate 4x4 Forum	patriotchassis.com (homepage)	High
Pirate 4x4 Forum	patriotchassis.com (Blazer chassis thread)	High
Fuel Curve	patriotchassis.com (K5 Blazer feature article)	High
Classic Broncos Forum	patriotchassis.com (forum mention)	Medium
Facebook	facebook.com/PatriotChassis/	High
Instagram	instagram.com/patriotchassis/	High

4. DNS & SSL Cutover Strategy

Since both old and new sites live on the same production server (prod-hetzner), this migration does not require a DNS change. The A records, MX records, and all other DNS records remain unchanged. This eliminates the riskiest part of most migrations.

Simplified migration: No DNS propagation delay. No email disruption risk from MX record changes. The cutover is a docroot file swap managed by dpanel’s deployment system, not a DNS change.

What Changes

Component	Old State	New State	Action Required
DNS A/AAAA records	Points to prod-hetzner	No change	None
MX records	mail.domain.com	No change	None
SPF/DKIM/DMARC	Configured	No change	None
SSL certificate	Let’s Encrypt (auto-renew)	Same cert, same auto-renew	None
Nginx vhost	Points to WP docroot	Points to new site docroot	dpanel deployment or manual update
PHP version	8.x (WP + WooCommerce)	8.3 (custom PHP API)	Verify PHP-FPM pool
Database	WordPress tables (wp_*)	Custom tables (pc_, thr_, ths_*)	Import/migrate data
Docroot files	WordPress core + theme + plugins	Custom HTML/CSS/JS + PHP	Deploy new files, archive old

SSL Verification

Since SSL certs are already provisioned and auto-renewing via dpanel for both domains, no SSL work is needed. However, verify post-deploy:

No mixed content warnings (all resources loaded via HTTPS)
Certificate covers domain.com, www.domain.com, and mail.domain.com
HSTS headers present if previously configured

Nginx Configuration Updates

The dpanel nginx vhost will need adjustments for the new site architecture:

# Key nginx directives for new sites:

# 1. PHP handling for product pages and API
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

# 2. Custom 404 page
error_page 404 /404.html;

# 3. Feed files with correct content types
location /feeds/google-merchant.xml {
    default_type application/xml;
}

# 4. Block direct access to admin API in production
# (optional: restrict by IP or require auth header)

Domain Confirmation

Confirmed: The production domain is thehighroadmanufacturing.com. This is the only active domain — research verified it has DNS records, an active WordPress site, and is the domain used in all business listings. The new site HTML correctly references this domain in canonical tags and structured data.

5. 301 Redirect Map — Patriot Chassis

Every URL that exists on the old WordPress site must either redirect to its equivalent on the new site or return a proper 410 Gone response. Never redirect to the homepage as a catch-all — this destroys page-level SEO equity.

Implementation: All redirects go in the .htaccess file in the new site’s docroot. Use RewriteRule with [R=301,L] flags. Redirects must be server-side (not JavaScript or meta refresh). Keep redirects active for a minimum of 1 year.

Page Redirects

Old URL	New URL	Notes
/	/	No redirect needed (same URL)
/products/	/shop.html	Main catalog page
/about/	/about.html	Direct equivalent
/contact/	/contact.html	Direct equivalent
/pages/contact-us	/contact.html	Alternate contact URL found in Google index
/custom-full-chassis/	/chassis.html	Full chassis landing page
/modular-chassis-system/	/chassis.html	Same destination, modular = chassis
/patriot-air-shock/	/air-shock.html	Air shock feature page
/patriot-air-ride/	/air-ride-request.html	Air ride quote request form
/patriot-suspension-components/	/shop.html	No direct equivalent; goes to shop
/chassis-components/	/shop.html	Category browsed via shop filters
/body-components/	/shop.html	Category browsed via shop filters
/badass-diy-products/	/shop.html	Category browsed via shop filters
/apparel-and-swag/	/shop.html	Category browsed via shop filters
/turnkey-full-builds/	/turnkey-builds.html	Direct equivalent
/turn-key-build-request/	/full-build.html	Build request form
/chassis-request/	/chassis-request.html	Direct equivalent
/badassery/	/faq.html	Info content → FAQ page
/patriot-chassis-pictures/	/gallery.html	Photo gallery
/patriot-chassis-videos/	/videos.html	Video library
/patriot-who/	/about.html	About/contact alternate
/collegues/	/partners.html	Partners page (fixes misspelling)
/policies/	/policies.html	Direct equivalent
/cart/	/cart.html	Shopping cart
/my-account/	/account.html	Account page
/checkout/	/cart.html	Stripe handles checkout; redirect to cart
/members/	/login.html	Members area → login
/member-product/	/shop.html	Member products → shop
/faq.html	—	Already exists on new site (no redirect needed)

Product Redirects (Pattern Rule)

All ~84 WooCommerce product URLs follow /product/{slug}/. The new site uses /product.php?p={slug}. A single pattern rule handles all products:

# Redirect all old WooCommerce product URLs to new product pages
RewriteRule ^product/([a-z0-9-]+)/?$ /product.php?p=$1 [R=301,L,QSA]

Trailing slash handling: WordPress URLs include trailing slashes (/product/patriot-air-shock-patent-pending/). The regex /?$ handles both with and without trailing slash. Test both variants.

Category Redirects (Pattern Rule)

WooCommerce category pages don’t have direct equivalents on the new site. Redirect them all to the shop page:

# Redirect all old product category pages to shop
RewriteRule ^product-category/(.*)$ /shop.html [R=301,L]

Tag Redirects (Pattern Rule)

67 product tags are thin taxonomy pages with minimal SEO value. Redirect all to shop:

# Redirect all old product tag pages to shop
RewriteRule ^product-tag/(.*)$ /shop.html [R=301,L]

WordPress Infrastructure Cleanup

# Block old WordPress paths that should not exist on new site
RewriteRule ^wp-admin(.*)$ / [R=301,L]
RewriteRule ^wp-login\.php$ /login.html [R=301,L]
RewriteRule ^wp-content/(.*)$ / [R=410,L]
RewriteRule ^wp-includes/(.*)$ / [R=410,L]

# Old WordPress sitemap URLs → new sitemap
RewriteRule ^wp-sitemap(.*)\.xml$ /sitemap.xml [R=301,L]
RewriteRule ^sitemap_index\.xml$ /sitemap.xml [R=301,L]

# Old WordPress feed URLs
RewriteRule ^feed/?$ / [R=301,L]

# Old blog/archive pages (dead content)
RewriteRule ^hello-world/?$ / [R=301,L]
RewriteRule ^2020/(.*)$ / [R=301,L]

# Test/junk pages that were indexed
RewriteRule ^test/?$ / [R=410,L]
RewriteRule ^lcp/?$ / [R=410,L]
RewriteRule ^sample-page/?$ / [R=410,L]

# HTML sitemap page
RewriteRule ^sitemap\.html$ /sitemap.xml [R=301,L]

Trailing Slash Normalization

The old WordPress site uses trailing slashes on all URLs. The new site uses .html extensions. Add a general rule to strip trailing slashes from page-level URLs:

# Strip trailing slashes and redirect to .html equivalent
# Only for pages that have a .html file
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1.html -f
RewriteRule ^([a-z0-9-]+)/?$ /$1.html [R=301,L]

6. 301 Redirect Map — The High Road Manufacturing

The old THR site has almost no SEO equity (3 indexed pages, broken WooCommerce). Redirects are still important for the few backlinks that exist and for any bookmarked URLs, but this is low-risk compared to Patriot Chassis.

Page Redirects

Old URL	New URL	Notes
/	/	No redirect needed
/about/	/about.html	Direct equivalent
/products/	/shop.html	Product catalog
/manufacturing/	/capabilities.html	Manufacturing → capabilities
/engineering/	/capabilities.html	Engineering → capabilities
/welding/	/welding.html	Direct equivalent
/cable-railing/	/capabilities.html	Product type → capabilities
/handrail/	/capabilities.html	Product type → capabilities
/contact-the-high-road/	/contact.html	Contact page
/high-road-team/	/about.html	Team page → about
/picture-gallery/	/gallery.html	Photo gallery
/affiliates/	/brands.html	Affiliates → brands
/information/	/faq.html	Info page → FAQ
/shop/	/shop.html	WooCommerce shop page
/cart/	/cart.html	Shopping cart
/my-account/	/account.html	Account management
/account/	/account.html	Duplicate account page
/checkout/	/cart.html	Checkout → cart (Stripe handles rest)
/login/	/login.html	Client login
/login-2/	/login.html	Duplicate login page
/register/	/register.html	Client registration
/registration/	/register.html	Alternate registration URL
/members/	/login.html	Members area → login
/user/	/account.html	User profile → account
/client-products/	/login.html	Client products → login (requires auth)
/policies/	/policies.html	Company policies
/equipment/	/equipment.html	Direct equivalent

Product Redirects (Pattern Rule)

# Redirect all old WooCommerce product URLs to new product pages
RewriteRule ^product/([a-z0-9-]+)/?$ /product.php?slug=$1 [R=301,L,QSA]

Category, Tag, and WordPress Cleanup

# Categories to shop
RewriteRule ^product-category/(.*)$ /shop.html [R=301,L]

# WordPress infrastructure
RewriteRule ^wp-admin(.*)$ / [R=301,L]
RewriteRule ^wp-login\.php$ /login.html [R=301,L]
RewriteRule ^wp-content/(.*)$ / [R=410,L]
RewriteRule ^wp-includes/(.*)$ / [R=410,L]
RewriteRule ^wp-sitemap(.*)\.xml$ /sitemap.xml [R=301,L]

# Junk pages
RewriteRule ^hello-world/?$ / [R=301,L]
RewriteRule ^sample-page/?$ / [R=410,L]
RewriteRule ^single-product/?$ /shop.html [R=301,L]
RewriteRule ^password-reset/?$ /login.html [R=301,L]
RewriteRule ^logout/?$ / [R=301,L]
RewriteRule ^category/(.*)$ / [R=301,L]

# Trailing slash normalization (same as PC)
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1.html -f
RewriteRule ^([a-z0-9-]+)/?$ /$1.html [R=301,L]

THR-Specific: Client Invoice Products

Private products in old site: The old THR WooCommerce site contains client-specific invoice products (e.g., /product/acme-invoice-166/, /product/37-crystal-ct-garage-level-pan-decking-install/) that should never have been publicly visible. The product pattern redirect will catch these and send them to the new product.php, which will show “Product Not Found” for non-existent slugs. This is acceptable — do not create specific redirects for client invoices.

7. Email Continuity

Email is the highest-risk component of any web migration. Lost email means lost business. For DominionPort sites, the risk is minimal because email and web hosting share the same server (prod-hetzner) and DNS records are not changing.

Low risk: Email infrastructure (Exim, Dovecot, SOGo) runs independently of the website docroot. Swapping website files does not affect email at all. MX records, SPF, DKIM, and DMARC records all remain unchanged.

Pre-Launch Email Verification

Verify MX records point to mail.patriotchassis.com and mail.thehighroadmanufacturing.com
Verify SPF, DKIM, and DMARC TXT records are present and correct
Send test emails to and from badass@patriotchassis.com before and after deploy
Verify webmail (SOGo) still works after deploy
Verify autodiscover/autoconfig endpoints still respond

New Site Email Configuration

The new sites send transactional email (contact form confirmations, order notifications). On production, these must use sendmail, not DevHub’s MailHog:

# .env on production (shared/ directory)
MAIL_METHOD=sendmail
# Exim auto-DKIM-signs outbound email for hosted domains
# No SMTP credentials needed when using sendmail

8. SEO Preservation

Critical On-Page Elements

The new sites must have these elements on every page. The Patriot Chassis site already has them (20/20 audit score). Verify they survive deployment:

Title tags: Unique per page, keyword-rich, under 60 characters
Meta descriptions: Unique per page, compelling, under 160 characters
Canonical tags: Every page has rel="canonical" pointing to production URL (not DevHub URL)
Open Graph tags: og:title, og:description, og:image, og:url
Twitter Card tags: twitter:card, twitter:title, twitter:description, twitter:image
JSON-LD structured data: Organization, Product (with price, availability, brand), BreadcrumbList
H1 tags: One per page, descriptive
Alt text: On all images, average 40+ characters
Internal links: Point to new URLs directly (not through redirects)

XML Sitemap

New sitemap.xml contains only new URLs (no old WordPress URLs)
All URLs in sitemap return HTTP 200
Sitemap referenced in robots.txt
Submit new sitemap to Google Search Console immediately after launch
Submit to Bing Webmaster Tools as well

robots.txt

# New robots.txt for both sites
User-agent: *
Allow: /

# Block admin and API paths from crawling
Disallow: /admin/
Disallow: /api/admin/
Disallow: /tools/

# Sitemap location
Sitemap: https://patriotchassis.com/sitemap.xml

Do NOT copy the old robots.txt. The old THR site has Disallow: /*? which blocks all URLs with query parameters — this would block product pages (/product.php?p=slug) from being crawled. The old PC site has Crawl-delay: 3 which unnecessarily slows Google’s crawl. Start fresh.

Google Search Console Actions

Verify ownership of both patriotchassis.com and thehighroadmanufacturing.com in Search Console (use DNS TXT record verification — already have DNS access via dpanel)
Since this is a same-domain migration (not a domain change), the “Change of Address” tool is not needed
Submit the new sitemap.xml on launch day
Use the URL Inspection tool to test 5–10 key pages and request indexing
Monitor the Index Coverage report daily for the first week

Expected SEO Recovery Timeline

Site	Expected Impact	Recovery Time
Patriot Chassis	Temporary ranking dip while Google processes redirects and reindexes	2–4 weeks if redirects are correct
The High Road Mfg	Likely immediate improvement — old site was broken	Immediate to 1 week

9. Pre-Launch Verification Checklist

Complete every item before deploying to production. This is the final gate.

Technical

No DevHub URLs in any source file — run tools/pre-deploy-audit.sh (mandatory, blocks deploy on failure). Scans for /config/workspace, devhub, preview.ecom.jj, devhub-mysql, devhub-mailhog, DB passwords, and preview gate PINs. Must exit 0 before devhub-deploy push.
.env file prepared for production (DB_HOST, DB_NAME, DB_USER, DB_PASS, SITE_URL, MAIL_METHOD, CORS_ORIGIN, Stripe keys)
All .htaccess redirect rules tested locally with curl -I
Product pages return 200 for all 83 PC products and all THR products
API endpoints return valid JSON (test contact, products, cart, webhook)
404 page works and returns HTTP 404 status code (not 200)
Forms submit successfully (contact, chassis request, air ride request, full build)
Stripe checkout works in test mode (cart → checkout → success page)
No noindex tags on public pages (only on checkout-success, checkout-cancel, quote, 404)
No staging auth/password protection remaining
All internal links use production URLs (not relative DevHub paths)
Cache-bust strings updated on all CSS/JS links (?v=YYYYMMDD)

Content

All product images load (check network tab for 404s on images)
Product data matches Hub (names, prices, descriptions, features)
Contact info correct: phone 509-675-7083, email badass@patriotchassis.com
Legal pages present: policies, privacy, terms
No placeholder text (“Lorem ipsum”, “TODO”, “FIXME”)

Performance

Performance audit passes 20/20 (Grade A) via performance-audit.sh
Page weight under 5MB on every page
No images over 500KB
WebP format for all product images
Font preload tags present
Core Web Vitals passing via PageSpeed Insights

Security

Admin auth strengthened for production (not just a simple token)
Stripe webhook signature validation enabled with production secret
CORS origin set to production domain (not wildcard, not DevHub)
API rate limiting active
No exposed debug information (error display off, no stack traces)
.env file not publicly accessible (blocked by .htaccess or nginx)

Database

Production database created with correct user and grants
Schema migration SQL ready in migrations/ directory
Product data imported via Hub push or migration script
Stripe product/price IDs set to production keys in database (not test keys)
Admin token set in production settings table

Feeds & Distribution

Google Merchant feed (feeds/google-merchant.xml) contains production URLs
Facebook catalog feed (feeds/facebook-catalog.csv) contains production URLs
Feed links use https://patriotchassis.com/ not DevHub preview URLs
Feed regeneration script tested

Backup

Old WordPress files archived (tarball stored off-server)
Old WordPress database dumped (mysqldump of all wp_* tables)
Old nginx vhost config saved
Archive stored in Backblaze B2 or Helsinki backup

10. Launch Day Procedure

This is the operational runbook for go-live. Execute steps in order. One site at a time — launch Patriot Chassis first (higher priority), monitor for 24 hours, then launch The High Road.

Recommended Launch Window

Early morning (5–7 AM Pacific / 8–10 AM Eastern) on a Tuesday, Wednesday, or Thursday. Avoids weekends (harder to get support), Mondays (catch-up traffic), and Fridays (no one wants to debug on Saturday).

T-60 Minutes: Final Prep

Archive the old site: tar -czf patriotchassis-old-$(date +%Y%m%d).tar.gz /home/patriotchassis/public_html/
Dump old database: mysqldump patriotchassis_wp > patriotchassis-wp-$(date +%Y%m%d).sql
Verify new site builds successfully on DevHub: devhub-deploy build
Send test email from production mail server to verify email works pre-deploy

T-0: Deploy

Deploy new site files: devhub-deploy push
Verify health check passes
Run production database migration (if needed)
Push product data from Hub to production site DB
Regenerate products-data.js on production
Verify .htaccess redirect rules are in place

T+5 Minutes: Smoke Test

Test	Expected Result	Command / URL
Homepage loads	HTTP 200, new design	`curl -I https://patriotchassis.com/`
Product page works	HTTP 200, product data renders	`curl -I https://patriotchassis.com/product.php?p=patriot-air-shock-patent-pending`
Old product URL redirects	HTTP 301 → new URL	`curl -I https://patriotchassis.com/product/patriot-air-shock-patent-pending/`
Shop page loads	HTTP 200, products grid	`curl -I https://patriotchassis.com/shop.html`
Old /products/ redirects	HTTP 301 → /shop.html	`curl -I https://patriotchassis.com/products/`
Contact form submits	Email received, success response	Manual browser test
Cart add/remove works	Cart updates, Stripe checkout loads	Manual browser test
404 page works	HTTP 404, custom 404 page	`curl -I https://patriotchassis.com/nonexistent-page`
SSL valid	Valid cert, no mixed content	`curl -vI https://patriotchassis.com/ 2>&1 \| grep subject`
Email works	Can send and receive	Send test to badass@patriotchassis.com

T+15 Minutes: SEO Activation

Submit new sitemap.xml to Google Search Console
Submit new sitemap.xml to Bing Webmaster Tools
Use URL Inspection tool on 5 key pages, request indexing
Verify robots.txt is accessible and correct: curl https://patriotchassis.com/robots.txt

T+30 Minutes: Feed Verification

Verify Google Merchant feed loads: curl https://patriotchassis.com/feeds/google-merchant.xml | head -20
Verify Facebook catalog feed loads: curl https://patriotchassis.com/feeds/facebook-catalog.csv | head -5
If using Google Merchant Center: update feed URL if it changed

11. Post-Launch Monitoring

Hour 0–4: Active Watch

Monitor server error logs: tail -f /var/log/nginx/error.log
Monitor access logs for 404 spikes: grep " 404 " access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
Verify analytics is receiving real-time data
Test all forms one more time from different devices/browsers
Check email delivery (send from contact form, verify received)

Hour 4–24: Sustained Monitoring

Set up uptime monitoring (UptimeRobot or similar, 1-minute intervals)
Review Google Search Console for new crawl errors
Check that Googlebot is crawling the new site (Search Console → Settings → Crawl stats)
Compare traffic to baseline — expect some fluctuation
Watch for unusual bounce rates or exit rates

Day 2–3: Stabilization

Run full site crawl with Screaming Frog to catch broken links
Review complete 404 log from access logs
Add missing redirects for any old URLs still generating traffic
Verify Google is indexing new URLs: site:patriotchassis.com search
Monitor keyword rankings (use Semrush, Ahrefs, or manual spot checks)

Day 4–7: Assessment

Compare Week 1 traffic to pre-migration baseline
Check Search Console Index Coverage — indexed page count should be rising
Verify Core Web Vitals data populating in Search Console
All redirects still working (deployments can break .htaccess)
Update Google Business Profile and social profiles (see Section 12)

Day 8–30: Recovery Tracking

Weekly ranking comparison against pre-migration benchmarks
Traffic should be recovering to baseline levels by Week 2–3
Any persistent 404s from access logs should have redirects by now
Old WordPress server/files can be decommissioned after Day 30 if stable

Day 90: Final Assessment

At 90 days post-migration, rankings should be fully recovered or improved. If traffic is still down, investigate: broken redirects, missing pages, canonical issues, or thin content.

12. Rollback Plan

If something goes catastrophically wrong, we can revert to the old WordPress site. Because this is a docroot swap on the same server, rollback is fast.

Rollback Triggers

Site-wide 500 errors that cannot be resolved within 30 minutes
Payment processing completely broken (Stripe webhook failures, checkout errors)
SSL certificate failure affecting all visitors
Severe traffic drop (>50%) with no explanation after 24 hours
Data integrity issues (corrupted database, missing products)

Rollback Procedure

Restore old files: Extract the archived tarball back to the docroot
Restore old database: Import the SQL dump taken pre-migration
Restore old nginx config: If vhost was modified, revert from saved copy
Clear caches: Restart PHP-FPM, clear any opcode caches
Verify: Confirm old WordPress site is serving correctly
Communicate: Notify stakeholders of rollback and new timeline

Rollback speed: Since the old files are pre-archived and the database dump is ready, rollback should take under 10 minutes. The versioned release system (devhub-deploy rollback) can also swap back to the previous release atomically.

Do NOT Rollback For

Minor styling issues (fix forward, don’t rollback)
Individual product page errors (fix the data, not the whole site)
Temporary ranking fluctuations (this is normal and expected)
A few missed redirects (add them, don’t rollback)

13. External Profile & Directory Updates

Update all external references to point to the new URL structure. Since the domain stays the same, most profile URLs don’t need changing — but any deep links to specific pages may break without updates.

Patriot Chassis

Platform	Current Link	Action
Facebook	facebook.com/PatriotChassis/	Update website link if it points to an inner page
Instagram	instagram.com/patriotchassis/	Update bio link to homepage or shop
Google Business Profile	patriotchassis.com	Verify website URL is `https://patriotchassis.com/`
Pirate 4x4 Forum	Thread links to homepage	No action needed (homepage URL unchanged)
Email signatures	Various links	Update any deep links in team email signatures
Printed materials	Business cards, brochures	Reprint if they reference old URL patterns
Google Merchant Center	Feed URL	Update feed URL if path changed
Facebook Commerce Manager	Catalog feed URL	Update catalog feed URL

The High Road Manufacturing

Platform	Current Link	Action
Alignable	alignable.com/ponderay-id/the-high-road-manufacturing	Update website URL
Google Business Profile	Verify exists, update URL	Create if not exists
Email signatures	Various	Update all team email signatures

Timing: Update external profiles on launch day or within 24 hours. Do not update before launch (broken links) or wait more than a week (stale references).

14. Analytics & Tracking Migration

Google Analytics 4 (GA4)

Since the domain is not changing, the existing GA4 property can continue to be used. However:

Install GA4 measurement tag on all pages of the new site (via components.js or direct script tag)
Verify events fire correctly: page_view, add_to_cart, begin_checkout, purchase
Add a note/annotation in GA4 marking the migration date
Filter out DevHub traffic by IP or hostname if not already done
Test real-time reports immediately after launch to confirm data flow

Conversion Tracking

Stripe webhook events fire correctly and record orders in the database
Contact form submissions tracked as conversions in GA4
Chassis/air-ride/build request submissions tracked as lead conversions

Search Console

Verify site ownership via DNS TXT record (already have access via dpanel)
Submit new sitemap on launch day
Request indexing for top 10 pages via URL Inspection tool
Monitor daily for first 7 days

Ad Platform Tracking

If running ads (Google Ads, Facebook Ads), verify:

Conversion pixels load on new site
Landing page URLs updated in ad campaigns (old URLs will redirect, but direct links are better)
Product feed URLs updated in shopping campaigns

15. Old Site Archiving

What to Archive

Item	Command / Method	Storage Location
Website files	`tar -czf pc-old-YYYYMMDD.tar.gz /home/patriotchassis/public_html/`	Backblaze B2 + Helsinki
WordPress database	`mysqldump patriotchassis_wp > pc-wp-YYYYMMDD.sql`	Backblaze B2 + Helsinki
Nginx vhost config	Copy from `/etc/nginx/sites-available/`	Same archive
PHP-FPM pool config	Copy from `/etc/php/8.3/fpm/pool.d/`	Same archive
Cron jobs	`crontab -l -u patriotchassis`	Same archive
Visual screenshots	Full-page screenshots of every page	Same archive

Wayback Machine

Before migration, manually submit key pages to the Wayback Machine for permanent public archival:

Homepage: https://web.archive.org/save/https://patriotchassis.com/
Products page: https://web.archive.org/save/https://patriotchassis.com/products/
About page: https://web.archive.org/save/https://patriotchassis.com/about/
Repeat for 5–10 key pages on each site

Retention

Keep the archive indefinitely. Storage is cheap. The old site content may be needed for legal, compliance, or content reference purposes. Do not delete the old WordPress database tables until at least 90 days post-migration and only after confirming all data has been successfully migrated.

16. Golden Rules

Never redirect to the homepage as a catch-all. Every old URL must redirect to its closest equivalent on the new site. Homepage redirects destroy page-level SEO equity and create a poor user experience.

Test every redirect before launch. Use curl -I on every redirect rule. A single syntax error in .htaccess can break the entire site. Test both with and without trailing slashes.

Keep redirects active for at least one year. Google recommends maintaining 301 redirects for a minimum of 1 year. Removing them too early causes 404 errors for anyone with bookmarks, backlinks, or cached search results.

Archive before you overwrite. Always create a complete backup (files + database + config) of the old site before deploying the new one. This is your safety net. No archive, no deploy.

Launch one site at a time. Deploy Patriot Chassis first (higher risk, more SEO equity). Monitor for 24 hours. Then deploy The High Road. Never launch both simultaneously — if something breaks, you need to know which site caused it.

Submit sitemaps immediately. The moment the new site is live, submit the new XML sitemap to Google Search Console and Bing Webmaster Tools. Do not wait. Every hour of delay is an hour Google might index old URLs without redirects.

Monitor access logs for 404s daily. The redirect map will never be 100% complete on day one. Real traffic will reveal missed URLs. Parse access logs daily for the first week and add redirects as needed.

Do not touch DNS unless you must. This migration is a docroot swap, not a server move. DNS records stay unchanged. Email stays unchanged. If you don’t need to change it, don’t. Every unnecessary change is unnecessary risk.

No DevHub URLs in production. Search every file for “devhub” before deploy. Database connections, API base URLs, CORS origins, canonical tags, Open Graph URLs, feed links — all must reference the production domain. One DevHub URL in a canonical tag can confuse Google for weeks.

Update external profiles on launch day. Google Business Profile, Facebook, Instagram, email signatures, ad campaigns, and merchant feeds. Don’t update before launch (creates broken links) and don’t delay more than 48 hours (stale references erode trust).

Site Migration & Launch

Contents

1. Migration Architecture Overview

Sites Being Migrated

Migration Flow

2. Priority Matrix — Must Do vs. Clean Up After

3. Pre-Migration Audit & Benchmarks

SEO Benchmarks to Record

Old Site Inventory — Patriot Chassis

Old Site Inventory — The High Road

Known External Backlinks — Patriot Chassis

4. DNS & SSL Cutover Strategy

What Changes

SSL Verification

Nginx Configuration Updates

Domain Confirmation

5. 301 Redirect Map — Patriot Chassis

Page Redirects

Product Redirects (Pattern Rule)

Category Redirects (Pattern Rule)

Tag Redirects (Pattern Rule)

WordPress Infrastructure Cleanup

Trailing Slash Normalization

6. 301 Redirect Map — The High Road Manufacturing

Page Redirects

Product Redirects (Pattern Rule)

Category, Tag, and WordPress Cleanup

THR-Specific: Client Invoice Products

7. Email Continuity

Pre-Launch Email Verification

New Site Email Configuration

8. SEO Preservation

Critical On-Page Elements

XML Sitemap

robots.txt

Google Search Console Actions

Expected SEO Recovery Timeline

9. Pre-Launch Verification Checklist

Technical

Content

Performance

Security

Database

Feeds & Distribution

Backup

10. Launch Day Procedure

Recommended Launch Window

T-60 Minutes: Final Prep

T-0: Deploy

T+5 Minutes: Smoke Test

T+15 Minutes: SEO Activation

T+30 Minutes: Feed Verification

11. Post-Launch Monitoring

Hour 0–4: Active Watch

Hour 4–24: Sustained Monitoring

Day 2–3: Stabilization

Day 4–7: Assessment

Day 8–30: Recovery Tracking

Day 90: Final Assessment

12. Rollback Plan

Rollback Triggers

Rollback Procedure

Do NOT Rollback For

13. External Profile & Directory Updates

Patriot Chassis

The High Road Manufacturing

14. Analytics & Tracking Migration

Google Analytics 4 (GA4)

Conversion Tracking

Search Console

Ad Platform Tracking

15. Old Site Archiving

What to Archive

Wayback Machine

Retention

16. Golden Rules