Site Migration Runbook in 2026: The 47-Step Process That Saves Rankings

Why Most Migrations Still Fail in 2026

I've run 31 platform migrations since 2019. Shopify to Shopify Plus, Shopify Plus to Hydrogen, WordPress monoliths to Next.js, Magento 2 to custom composable stacks. The median client comes to me after a botched migration with a chart that looks like a cliff edge. They want me to explain what happened. Most of the time I can explain it in a single sentence: the team treated the migration as a deployment problem rather than a search-equity problem.

Deploying a new platform correctly and migrating search equity correctly are two completely different disciplines that happen to share a launch date.

The migration I'm documenting here is specific. In late 2025 I managed the move of a 4.1-million-URL Shopify Plus catalog to Hydrogen (React Server Components, Vite build, Oxygen CDN deployment) for a UK-based health and wellness retailer. Simultaneously, I consulted on a 3.8-million-URL WordPress-to-Next.js migration for a US media property. Between those two engagements I developed what I now call the FREEZE framework, and I'm going to walk you through all 47 steps of it.

The Hydrogen migration landed with a measured organic traffic delta of +0.3% at 90 days post-cutover. Not zero loss, technically, but within normal seasonal variance. The Next.js migration hit -2.1% at 30 days before recovering to +4.7% at 90. Neither client lost meaningful ground. Here's how.

Two Things the Migration Industry Gets Wrong

Contrarian Take 1: Pre-migration crawls are overvalued; pre-migration rendering audits are undervalued

Every migration checklist in existence tells you to crawl the origin site before you move. Run Screaming Frog. Export URLs. Count status codes. Fine. That's table stakes. But in 2026, when the destination platform is Hydrogen or Next.js or any RSC-based framework, a URL inventory is nearly useless without a parallel rendering audit.

Here's the specific failure mode I see constantly: a product detail page on the origin Shopify Plus store renders price, review count, and structured data (Product schema) fully in HTML. The migration team builds the Hydrogen equivalent. The RSC server component renders the shell. A client component hydrates the price and review count. The structured data is injected via a client-side useEffect hook because the developer found a tutorial that did it that way. Googlebot renders the page, sees the schema, but the timing of the client-side injection means the JSON-LD is sometimes present and sometimes not in the rendered DOM snapshot. The rich result fluctuates. Impressions drop 11% before anyone notices.

I mandate a rendering audit before any line of redirect mapping begins. Every template type, every schema type, every dynamic injection point must be verified against a headless Chrome rendering environment before the first redirect fires.

Contrarian Take 2: The "migration window" mindset creates the disasters it's designed to prevent

The industry consensus is to pick a low-traffic day, usually Tuesday or Wednesday, and do the migration in a compressed window. The logic is that you minimize the period of instability. I think this is backwards for large sites.

For catalogs above 500,000 URLs, a compressed migration window means Googlebot encounters millions of 301 redirects in a 24–48 hour burst. The crawl rate spikes, then throttles. The redirect graph takes weeks to process fully. Canonicalization signals conflict during that processing window. You get ranking volatility that a staged rollout would have avoided entirely.

My approach since mid-2025 is a staged URL namespace migration: move product categories in order of crawl priority, verified via Google Search Console crawl stats, over a 3-to-4-week period. The redirects process incrementally. Index updates flow continuously. The volatility curve flattens dramatically. This is slower, more operationally complex, and nearly impossible to sell to a project manager. Do it anyway.

The Migration That Lost 14% (What I Learned)

In Q1 2025 I managed a 920,000-URL Magento 2 to Shopify Plus migration for a European consumer electronics retailer. We hit every checklist item. Redirect map was complete. Sitemaps submitted. GSC property verified. Change of address filed. Canonical tags updated.

We lost 14.3% of non-branded organic traffic at the 30-day mark. At 60 days we were still at -9.1%. We recovered to -3.2% by day 90 and never fully closed the gap in the engagement I was retained for.

The post-mortem identified three compounding failures. First: the site had 847 URL parameters that generated unique canonical URLs in Magento but were handled as faceted navigation in Shopify's URL structure. Those 847 parameter combinations represented 23% of the top-500 landing pages in GSC. We redirected the canonical URLs correctly but missed the parameter variants, which had accumulated link equity independently over six years. Second: the international hreflang annotations referenced the Magento URL structure by absolute URL. We updated them in the sitemap but missed 14 hardcoded references in the theme templates. Third: and this is the one that still bothers me, we ran the soft-launch protocol for 72 hours rather than the 14 days I now require as a minimum. We caught rendering issues in the soft-launch but didn't have enough GSC data to see the hreflang problem before we went hard.

Fourteen percent. Three fixable things. The lesson is not that migrations are hard. The lesson is that the validation window must be longer than feels comfortable, and URL parameter equity deserves its own audit category.

The FREEZE Framework

FREEZE is the personal framework I developed to structure large platform migrations. The acronym maps to the five phases:

• Freeze the origin (inventory, baseline, content lock)
• Redirect architecture (map, test, stage)
• Environment validation (rendering, schema, Core Web Vitals)
• Ease in with soft-launch (staged rollout, monitoring)
• Zero-gap cutover (hard switch, GSC handoff)
• Extended monitoring (30/60/90-day windows)

The rest of this article walks through all 47 steps organized under those five phases, plus the extended monitoring window. Code samples reflect the actual tooling used in the Hydrogen and Next.js migrations.

Phase 1: Inventory and Baseline (Steps 1–11)

Step 1: Export the full crawlable URL set

Do not rely on the CMS sitemap alone. For the Hydrogen migration, the Shopify Plus sitemap covered 2.1 million of 4.1 million URLs. The remaining 2 million were generated by parameterized collection filters, legacy blog redirects, and product variant URLs that Shopify excludes from its default sitemap generation. You need both.

# Crawl origin site and export full URL list with status codes
# Using Scrapy with custom settings for large catalogs

scrapy crawl full_site \
  --set CONCURRENT_REQUESTS=16 \
  --set DOWNLOAD_DELAY=0.25 \
  --set DEPTH_LIMIT=8 \
  --set HTTPCACHE_ENABLED=True \
  -o origin_urls_$(date +%Y%m%d).jsonl

# Merge with sitemap URLs
python3 merge_url_sources.py \
  --crawl origin_urls_20251104.jsonl \
  --sitemap sitemap_index_export.xml \
  --gsc gsc_top_pages_16months.csv \
  --output full_url_inventory_deduplicated.csv

Step 2: Pull 16 months of GSC data

12 months captures seasonality. 16 months gives you a comparison buffer that survives algorithm update volatility. Pull clicks, impressions, average position, and CTR for every URL in the inventory. This becomes your baseline measurement set.

from googleapiclient.discovery import build
from google.oauth2 import service_account
import pandas as pd
from datetime import datetime, timedelta

SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'gsc-service-account.json'

credentials = service_account.Credentials.from_service_account_file(
    SERVICE_ACCOUNT_FILE, scopes=SCOPES)
service = build('searchconsole', 'v1', credentials=credentials)

def fetch_gsc_data(site_url, start_date, end_date, row_limit=25000):
    request = {
        'startDate': start_date,
        'endDate': end_date,
        'dimensions': ['page', 'query', 'device', 'country'],
        'rowLimit': row_limit,
        'dataState': 'final'
    }
    response = service.searchanalytics().query(
        siteUrl=site_url, body=request).execute()
    return pd.DataFrame(response.get('rows', []))

# Fetch 16-month window in 3-month chunks to avoid row limits
date_ranges = [
    ('2024-07-01', '2024-09-30'),
    ('2024-10-01', '2024-12-31'),
    ('2025-01-01', '2025-03-31'),
    ('2025-04-01', '2025-06-30'),
    ('2025-07-01', '2025-09-30'),
]

frames = [fetch_gsc_data('sc-domain:example.com', s, e) for s, e in date_ranges]
baseline = pd.concat(frames).drop_duplicates()
baseline.to_parquet('gsc_baseline_16mo.parquet', index=False)

Step 3: Identify the top-2000 landing pages by traffic

Every URL gets migrated. But the top-2000 by clicks over 16 months get individual QA treatment. Not sampling. Individual. This list is your migration's source of truth.

Step 4: Tag URL types by template

For the Hydrogen migration, URL types were: homepage, collection (top-level), collection (filtered), product detail, product variant, blog index, blog post, static page, account/authentication (noindex), search results (noindex). Each template type needs its own validation checklist because the rendering stack is different.

Step 5: Run a rendering audit on template types

# Render each template type using headless Chrome
# Compare rendered DOM against raw HTML for content parity

from playwright.async_api import async_playwright
import asyncio
import json

async def render_url(url):
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page(
            user_agent='Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
        )
        await page.goto(url, wait_until='networkidle')
        content = await page.content()

        # Extract JSON-LD blocks
        ld_blocks = await page.evaluate('''() => {
            const scripts = document.querySelectorAll('script[type="application/ld+json"]');
            return Array.from(scripts).map(s => s.textContent);
        }''')

        await browser.close()
        return {
            'url': url,
            'rendered_html_length': len(content),
            'json_ld_count': len(ld_blocks),
            'json_ld_types': [json.loads(b).get('@type') for b in ld_blocks if b]
        }

async def audit_templates(url_list):
    tasks = [render_url(url) for url in url_list]
    return await asyncio.gather(*tasks)

sample_urls = [
    'https://origin.example.com/',
    'https://origin.example.com/collections/supplements',
    'https://origin.example.com/products/vitamin-d3-5000iu',
    'https://origin.example.com/blogs/news/post-slug',
]

results = asyncio.run(audit_templates(sample_urls))
print(json.dumps(results, indent=2))

Step 6: Capture Core Web Vitals baseline per template

Use CrUX API, not lab data. The origin platform's field data is your benchmark. If the destination platform improves CWV, great. If it regresses, you need to know before launch.

Step 7: Audit all structured data types on origin

Product, Organization, BreadcrumbList, FAQPage, Article, Review, ItemList. Every schema type present on origin must be present and valid on destination. Use the Rich Results Test API for the top-2000 URLs. Automate it.

Step 8: Export internal link graph

You need the internal link graph to validate that high-equity pages on destination maintain the same internal linking depth they had on origin. A page that was 2 clicks from the homepage on Shopify Plus cannot become 5 clicks from the homepage on Hydrogen without planning a compensating internal link injection.

Step 9: Document all canonical configurations

Paginated series, parameter handling, hreflang cross-references, self-referential canonicals. Every variant. Export to a structured CSV you can diff against the destination configuration post-launch.

Step 10: Freeze the origin content

No new content. No URL changes. No structural edits. The origin site is a snapshot from this point. This sounds obvious. It gets violated constantly. Build a documented content freeze policy and get sign-off from content and merchandising teams before you proceed.

Step 11: Establish pre-migration traffic baseline report

Create a Looker Studio dashboard (or your reporting tool of choice) that will serve as the migration health scorecard. Metrics: organic sessions by template type, impressions by URL cluster, average position for the top-200 keywords, crawl coverage in GSC. You'll compare this against post-migration data at 30, 60, and 90 days.

Phase 2: Redirect Architecture (Steps 12–21)

Step 12: Build the redirect map in three layers

Layer 1: exact URL-to-URL matches (most URLs). Layer 2: pattern-based rules for URL families that share a structure transformation. Layer 3: exception rules for URLs that break the pattern. Most migrations fail at Layer 3 because the exceptions are undocumented until someone notices a 404.

# redirect_map_structure.py
# Three-layer redirect architecture

import re
import csv

# Layer 1: Exact matches (loaded from CMS export or manual mapping)
exact_redirects = {
    '/old-product-slug': '/products/new-product-slug',
    '/collections/old-cat': '/collections/new-cat',
    # ... 4.1M entries loaded from CSV
}

# Layer 2: Pattern-based rules
pattern_redirects = [
    # Shopify Plus to Hydrogen: collection URL structure unchanged
    (r'^/collections/([a-z0-9\-]+)$', r'/collections/\1'),
    # Product URLs: old format /p/SKU-123 -> /products/sku-123
    (r'^/p/([A-Z0-9\-]+)$', lambda m: f'/products/{m.group(1).lower()}'),
    # Blog posts: /blog/YYYY/MM/slug -> /blogs/news/slug
    (r'^/blog/\d{4}/\d{2}/(.+)$', r'/blogs/news/\1'),
    # Parameterized collection filters -> canonical collection
    (r'^/collections/([a-z0-9\-]+)\?.*$', r'/collections/\1'),
]

# Layer 3: Exceptions override patterns
exception_redirects = {
    '/collections/sale?sort_by=price-ascending': '/collections/sale',
    '/collections/new-in': '/collections/new-arrivals',
}

def resolve_redirect(path):
    # Exception check first
    if path in exception_redirects:
        return exception_redirects[path], 'exception'

    # Exact match
    if path in exact_redirects:
        return exact_redirects[path], 'exact'

    # Pattern match
    for pattern, replacement in pattern_redirects:
        match = re.match(pattern, path)
        if match:
            if callable(replacement):
                return replacement(match), 'pattern'
            return re.sub(pattern, replacement, path), 'pattern'

    return None, 'unmapped'

Step 13: Identify redirect chains from origin

The origin site has chains. Every site that's been running for more than three years has chains. Find them before you build the destination redirect map or you'll bake the chains into the new platform.

# Detect redirect chains on origin
# Using httpx for async requests

import httpx
import asyncio

async def follow_chain(client, url, max_hops=10):
    chain = [url]
    current = url
    for _ in range(max_hops):
        try:
            r = await client.get(current, follow_redirects=False)
            if r.status_code in (301, 302, 307, 308):
                location = r.headers.get('location', '')
                chain.append({'status': r.status_code, 'location': location})
                current = location
            else:
                chain.append({'status': r.status_code, 'final': True})
                break
        except Exception as e:
            chain.append({'error': str(e)})
            break
    return chain

async def audit_chains(urls):
    limits = httpx.Limits(max_connections=50)
    async with httpx.AsyncClient(limits=limits, timeout=10) as client:
        tasks = [follow_chain(client, u) for u in urls]
        return await asyncio.gather(*tasks)

# Flag chains longer than 1 hop for flattening
results = asyncio.run(audit_chains(all_origin_urls))
chains = [(u, r) for u, r in zip(all_origin_urls, results) if len(r) > 2]
print(f'Found {len(chains)} chained redirects to flatten')

Step 14: Map parameter equity separately

This is the lesson from the -14% migration. Pull every URL variant with GSC clicks from the 16-month export. Any parameterized URL that received more than 50 clicks gets its own explicit redirect entry, not a catch-all parameter strip.

Step 15: Validate redirect map against GSC top pages

Every URL in your top-2000 GSC landing pages list must resolve to a 200 on the destination, via a maximum of one 301. Script this validation against the staging environment.

Step 16: Implement redirects at the edge

For the Hydrogen migration, redirects were implemented in Oxygen's edge routing layer. For the Next.js migration, in Next.js middleware and Vercel's edge config. Not in the application layer. Not in htaccess. At the edge, before any application logic runs. Speed of redirect resolution affects crawl budget consumption during the migration window.

// next.config.js - redirect configuration for Next.js migration
// Large redirect sets should use Edge Middleware, not next.config.js redirects
// next.config.js is for small sets only

/** @type {import('next').NextConfig} */
const nextConfig = {
  async redirects() {
    // Only structural/permanent pattern redirects here
    return [
      {
        source: '/blog/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/articles/:slug',
        permanent: true,
      },
      {
        source: '/category/:slug*',
        destination: '/topics/:slug*',
        permanent: true,
      },
      {
        source: '/author/:name',
        destination: '/writers/:name',
        permanent: true,
      },
    ]
  },
}

module.exports = nextConfig

// middleware.ts - Edge Middleware for bulk URL redirect lookup
// Vercel Edge Config stores up to 512KB of redirect map JSON

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { get } from '@vercel/edge-config'

export async function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname

  // Fast path: skip known non-redirect paths
  if (
    pathname.startsWith('/_next') ||
    pathname.startsWith('/api') ||
    pathname.includes('.')
  ) {
    return NextResponse.next()
  }

  try {
    const redirectMap = await get>('redirects')
    if (redirectMap && redirectMap[pathname]) {
      const destination = redirectMap[pathname]
      return NextResponse.redirect(
        new URL(destination, request.url),
        { status: 301 }
      )
    }
  } catch (e) {
    // Edge Config unavailable - fail open
    console.error('Edge Config error:', e)
  }

  return NextResponse.next()
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

Step 17: Test redirect map in staging with 5,000-URL sample

Automated. Random sample weighted by GSC traffic. Every URL must return the expected destination with status 301 and correct Location header. Failures block launch.

Step 18: Document the redirect implementation for the dev team

Not a Notion doc. A versioned spec in the repo. The implementation is a contract between SEO and engineering and it needs to be treated like one.

Step 19: Audit destination for self-referential canonicals

Every page on the destination must have a canonical that points to itself, using the destination domain, before any traffic is routed. Canonical pointing to the origin domain after cutover is a common failure mode in headless builds where the canonical is set by a CMS field that still contains the old domain.

Step 20: Verify hreflang on destination (if applicable)

Absolute URLs. Correct domain. Correct locale codes. X-default present. Cross-references valid. The 14% loss migration failed here. Don't fail here.

Step 21: Freeze the redirect map

No changes to the redirect map after this point without documented sign-off. This is a release artifact.

Phase 3: Sitemap Freeze and Thaw Protocol (Steps 22–28)

Step 22: Understand the sitemap freeze concept

Sitemap freezing means: you stop generating dynamic sitemaps on the origin platform and replace them with static XML files that represent the final, canonical URL set you intend to migrate. This prevents the origin sitemap from updating with new URLs during the migration window, which would create targets Googlebot might try to crawl after you've cut over.

Step 23: Generate static XML sitemaps for origin

#!/usr/bin/env python3
# sitemap_freeze.py
# Generates static sitemap XML from URL inventory

import xml.etree.ElementTree as ET
from datetime import datetime
import math
import gzip
import shutil

SITEMAP_MAX_URLS = 48000  # Below 50k limit for safety margin
BASE_URL = 'https://origin.example.com'

def generate_sitemap_chunk(urls, filename, priority_map=None):
    urlset = ET.Element('urlset')
    urlset.set('xmlns', 'http://www.sitemaps.org/schemas/sitemap/0.9')

    for url in urls:
        url_el = ET.SubElement(urlset, 'url')
        loc = ET.SubElement(url_el, 'loc')
        loc.text = url['loc']

        lastmod = ET.SubElement(url_el, 'lastmod')
        lastmod.text = url.get('lastmod', datetime.now().strftime('%Y-%m-%d'))

        priority_val = priority_map.get(url['loc'], '0.5') if priority_map else '0.5'
        priority = ET.SubElement(url_el, 'priority')
        priority.text = priority_val

    tree = ET.ElementTree(urlset)
    ET.indent(tree, space='  ')

    with open(filename, 'wb') as f:
        tree.write(f, encoding='utf-8', xml_declaration=True)

    # Gzip for serving
    with open(filename, 'rb') as f_in:
        with gzip.open(f'{filename}.gz', 'wb') as f_out:
            shutil.copyfileobj(f_in, f_out)

def generate_sitemap_index(sitemap_files, index_filename):
    sitemapindex = ET.Element('sitemapindex')
    sitemapindex.set('xmlns', 'http://www.sitemaps.org/schemas/sitemap/0.9')

    for sf in sitemap_files:
        sitemap_el = ET.SubElement(sitemapindex, 'sitemap')
        loc = ET.SubElement(sitemap_el, 'loc')
        loc.text = f'{BASE_URL}/sitemaps/{sf}'

        lastmod = ET.SubElement(sitemap_el, 'lastmod')
        lastmod.text = datetime.now().strftime('%Y-%m-%d')

    tree = ET.ElementTree(sitemapindex)
    ET.indent(tree, space='  ')
    tree.write(index_filename, encoding='unicode', xml_declaration=True)

# Load full URL inventory
import csv
all_urls = []
with open('full_url_inventory_deduplicated.csv') as f:
    reader = csv.DictReader(f)
    all_urls = [{'loc': row['url'], 'lastmod': row.get('lastmod', '')}
                for row in reader if row['status'] == '200']

print(f'Total URLs to freeze: {len(all_urls):,}')

# Chunk into sitemap files
chunks = [all_urls[i:i+SITEMAP_MAX_URLS]
          for i in range(0, len(all_urls), SITEMAP_MAX_URLS)]

sitemap_files = []
for idx, chunk in enumerate(chunks):
    filename = f'sitemap-{idx+1:03d}.xml'
    generate_sitemap_chunk(chunk, f'frozen_sitemaps/{filename}')
    sitemap_files.append(filename)
    print(f'Generated {filename}: {len(chunk):,} URLs')

generate_sitemap_index(sitemap_files, 'frozen_sitemaps/sitemap_index_frozen.xml')
print(f'Sitemap index generated with {len(sitemap_files)} sitemaps')

Step 24: Deploy frozen sitemaps to origin

Replace the dynamic sitemap generation with static file serving. On Shopify Plus this means disabling the default sitemap.xml generation and routing /sitemap.xml to a hosted static file. On WordPress this means disabling Yoast or RankMath sitemap generation and serving static files via a redirect rule.

Step 25: Verify frozen sitemaps in GSC

Submit the frozen sitemap index to GSC. Confirm the URLs discovered match the frozen inventory count. Give Googlebot 48 hours to acknowledge the submission before proceeding.

Step 26: Prepare destination sitemaps

The destination sitemaps should be built and ready but NOT submitted to GSC yet. They should be accessible at the correct path on the destination domain, verified as valid XML, and contain only URLs that return 200 on the destination staging environment.

Step 27: Build sitemap thaw automation

#!/bin/bash
# sitemap_thaw.sh
# Run post-cutover to activate destination sitemaps in GSC

SITE_URL="https://www.example.com"
GSC_TOKEN=$(cat gsc_oauth_token.json | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

# Submit new sitemap index
curl -s -X PUT \
  "https://www.googleapis.com/webmasters/v3/sites/$(python3 -c "import urllib.parse; print(urllib.parse.quote('$SITE_URL', safe=''))")/sitemaps/$(python3 -c "import urllib.parse; print(urllib.parse.quote('$SITE_URL/sitemap_index.xml', safe=''))")" \
  -H "Authorization: Bearer $GSC_TOKEN" \
  -H "Content-Type: application/json"

echo "Sitemap index submitted: $SITE_URL/sitemap_index.xml"

# Verify submission
curl -s \
  "https://www.googleapis.com/webmasters/v3/sites/$(python3 -c "import urllib.parse; print(urllib.parse.quote('$SITE_URL', safe=''))")/sitemaps" \
  -H "Authorization: Bearer $GSC_TOKEN" | python3 -m json.tool

Step 28: Document the thaw trigger conditions

The sitemap thaw (submitting destination sitemaps, withdrawing origin sitemaps) happens at a specific trigger: hard cutover confirmed, 200 responses verified across template types, redirects validated in production. Not before. Write this down. Get sign-off.

Phase 4: Soft-Launch and Crawl Validation (Steps 29–37)

Step 29: Define soft-launch architecture

Soft-launch means: destination platform is live on a separate subdomain or behind an IP allowlist, receiving no organic traffic, with a robots.txt disallowing all crawlers. You QA everything here before redirects fire.

For the Hydrogen migration, the soft-launch environment was staging.example.com with a restrictive robots.txt and Cloudflare access authentication preventing public access. Organic traffic continued flowing to origin throughout the soft-launch period.

Step 30: Validate all top-2000 URLs on soft-launch

# validate_soft_launch.py
# Automated validation of top-2000 URLs on staging environment

import asyncio
import httpx
import json
from urllib.parse import urlparse, urljoin

STAGING_BASE = 'https://staging.example.com'
ORIGIN_BASE = 'https://www.example.com'
AUTH_HEADERS = {'CF-Access-Client-Id': 'xxx', 'CF-Access-Client-Secret': 'yyy'}

async def validate_url(client, origin_url):
    staging_path = urlparse(origin_url).path
    staging_url = urljoin(STAGING_BASE, staging_path)

    result = {
        'origin_url': origin_url,
        'staging_url': staging_url,
        'checks': {}
    }

    try:
        r = await client.get(staging_url, headers=AUTH_HEADERS, follow_redirects=True)
        result['checks']['status_200'] = r.status_code == 200
        result['checks']['canonical_self'] = (
            f'rel="canonical"' in r.text and
            staging_url.replace(STAGING_BASE, ORIGIN_BASE) in r.text
        )
        result['checks']['has_json_ld'] = 'application/ld+json' in r.text
        result['checks']['has_title'] = '