Website Migration Audit logo

Website Migration Audit

Organization
cognyai
website-migration-audit

Compare a production site against a staging/redesign version — SEO parity, content integrity, missing pages, and launch readiness

Overview

Publishercognyai
Repositoryclaude-code-marketing-skills
Skill namewebsite-migration-audit
Stars
111
Forks
15
Bundled files
Instructions only
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by cognyai on GitHub. Read the source before you install it.

Installation

Install the Website Migration Audit AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/cognyai/claude-code-marketing-skills/tree/main/skills/website-migration-audit
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/cognyai/claude-code-marketing-skills.git /tmp/claude-code-marketing-skills
mkdir -p .claude/skills
cp -r /tmp/claude-code-marketing-skills/skills/website-migration-audit .claude/skills/website-migration-audit
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Website Migration Audit in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Website Migration Audit on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Website Migration Audit is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Website Migration Audit

Compare a production website against a staging or redesigned version to catch SEO regressions, missing pages, content drift, and launch blockers before going live.

Use this skill when a site is being rebuilt, redesigned, re-platformed, or migrated to a new CMS — especially when the work is done by an external consultant or agency and needs review before launch.

Usage

/website-migration-audit example.com staging.example.com
/website-migration-audit example.com staging.example.com --deep

Instructions

You are a website migration QA specialist. Your job is to protect the client's existing SEO equity, content accuracy, and user experience during a site migration. You are thorough, methodical, and biased toward caution — a missed 404 on a top-ranking page can cost months of organic traffic.

When both URLs are provided, run the full audit below. If Cogny MCP tools are available, use Search Console or BigQuery data to prioritize pages by actual traffic (clicks, impressions, rankings). Without MCP, fall back to sitemap crawling and public data.

Works with

Runs with zero accounts (sitemap + curl). If Cogny is connected, the providers below make the page list complete and traffic-weighted; if it isn't, use the "No account" column and say in the report that priorities come from navigation and sitemap order, not traffic.

JobPrimaryAlso answers itNo account
Top pages by trafficGoogle Search Console (tool_get_search_analytics)BigQuery GSC export (Cloud only), Bing Webmaster (tool_get_page_stats)Rank by nav/sitemap order (no traffic data)
Pages with backlinks (must redirect)Ahrefs (top_pages, backlinks)Semrush (backlinks), Bing (tool_get_url_links)—
Full page inventory, old and newThe CMS on each side: WordPress, Webflow, Ghost, Framer, Sanity, Contentful, Shopify—sitemap.xml
Existing redirectsWebflow, Framer, Shopify (list_redirects)—Fetch old URLs and follow 301s

If Cogny is connected, call mcp__cogny__list_integrations first and flag unhealthy integrations. If an expected tool is missing, call mcp__cogny__refresh_mcp_discovery once.


Steps

1. Identify top SEO pages on the production site

With Cogny MCP (preferred): If Cogny isn't connected, skip this and note what connecting adds (real clicks per URL, so tiers reflect traffic). Otherwise get the top 25 pages by clicks over the last 3 months. Record clicks, impressions, CTR, and average position for each.

  • Solo or Cloud: mcp__cogny__mcp__Google_Search_Console__tool_get_search_analytics (site_url, start_date, end_date, dimensions: ["page"], row_limit: 25).
  • Cloud only, if a GSC BigQuery export exists: the SQL below covers longer history.
  • Bing too: mcp__cogny__mcp__Bing_Webmaster_Tools__tool_get_page_stats (site_url). Add Bing-only pages to the list; show Bing clicks in their own column.
sql
-- Example: BigQuery Search Console export
SELECT
  url,
  SUM(clicks) AS total_clicks,
  SUM(impressions) AS total_impressions,
  ROUND(SAFE_DIVIDE(SUM(clicks), SUM(impressions)) * 100, 2) AS ctr_pct,
  ROUND(SAFE_DIVIDE(SUM(sum_position), SUM(impressions)), 1) AS avg_position
FROM `searchconsole.searchdata_url_impression`
WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
  AND search_type = 'WEB'
GROUP BY url
ORDER BY total_clicks DESC
LIMIT 25

Without MCP: Fetch /sitemap.xml (and any sitemap index children) from the production site with curl -sL and extract all URLs. Without traffic data, rank pages by prominence instead:

  1. Homepage
  2. Top-navigation links, in menu order (curl the homepage and extract <nav>/header <a href>s)
  3. Footer links that aren't legal boilerplate
  4. Remaining sitemap URLs in sitemap order (many CMSs list key pages first)

Label the tiers "by nav/sitemap order, not traffic" in the report. WebSearch ignores site:, so don't use it to estimate visibility.

Backlinked pages (enhanced when connected): If Cogny isn't connected, skip this and note what connecting adds (URLs with external links that must keep a 301). A page with few clicks but many referring domains still needs a 301. Pull mcp__cogny__mcp__Ahrefs__top_pages (target, country) and mcp__cogny__mcp__Ahrefs__backlinks (target, limit: 100) or mcp__cogny__mcp__Semrush__backlinks (target). Raise any URL with external links to at least the High tier.

1b. Inventory pages from the CMS (enhanced when connected)

If Cogny isn't connected, skip this and note what connecting adds (drafts, unlisted pages and existing redirects that a sitemap misses).

Sitemaps miss drafts, unlisted pages and CMS collection items. If the old or new platform is connected, list everything from the source and diff the two inventories by slug/path:

CMSPagesPosts / collection itemsRedirects
WordPressWordPress__list_pages (per_page: 100, page)WordPress__list_posts (per_page: 100, page)— (plugin-managed; fetch old URLs)
WebflowWebflow__list_sites → Webflow__list_pages (site_id)Webflow__list_collections → Webflow__list_items (collection_id)Webflow__list_redirects (site_id)
GhostGhost__list_pagesGhost__list_posts (limit, page)—
Framer—Framer__list_collections → Framer__get_collection_items (collection_id)Framer__list_redirects
Sanity—Sanity__tool_list_documents (document_type) or Sanity__tool_query_groq (query)—
Contentful—Contentful__contentful_list_content_types → Contentful__contentful_list_entries (content_type)—
ShopifyShopify__tool_list_pagesShopify__tool_list_products, tool_list_collections, tool_list_articles (first: 50, after)Shopify__tool_list_redirects

Prefix every name above with mcp__cogny__mcp__. Paginate until empty. Every production path that is missing on the new side and has no redirect goes into step 2 as a candidate 404. Creating redirects (Webflow__create_redirect, Shopify__tool_create_redirect, Framer__add_redirects) is a write: list them in the report and ask first.

Classify pages into priority tiers:

  • Critical (top 5 by clicks) — any issue is a launch blocker
  • High (top 6-15) — issues should be fixed before launch
  • Medium (top 16-25) — issues should be fixed within first week
  • Standard (all remaining) — verify they exist, spot-check content

2. URL parity check

First, confirm staging is a separate site. Many staging hosts just 301 to production, which makes every check "pass" against production itself:

bash
for u in "https://<staging>/" "https://<staging>/<a-deep-path>/"; do
  curl -sL -o /dev/null -w "%{http_code} %{url_effective} (%{num_redirects} redirects)\n" "$u"
done

If the final URL (url_effective) lands on the production host, stop the parity checks and report: "Staging redirects to production; nothing to compare. Need a reachable staging URL (or basic-auth credentials / an IP allowlist)." Also stop if staging returns 401/403 to every request, and ask for access. Compare final URLs, not just status codes, for every pair below.

For every production URL found in step 1 (plus sitemap, key navigation pages, and legal pages like privacy policy), fetch the equivalent path on the staging site.

Record the HTTP status:

  • 200 — page exists, proceed to content comparison
  • 301/302 — note the redirect target, verify it's intentional
  • 404 — flag as blocker if Critical/High tier, warning if Medium/Standard
  • 500 — flag as blocker regardless of tier

Present results as a table:

URL Parity Check: [production] vs [staging]

BLOCKERS:
| URL               | Prod Status | Staging Status | Traffic (3mo) | Tier     |
|-------------------|-------------|----------------|---------------|----------|
| /important-page/  | 200         | 404            | 500 clicks    | Critical |

OK:
| URL               | Prod Status | Staging Status | Tier     |
|-------------------|-------------|----------------|----------|
| /                 | 200         | 200            | Critical |
| /services/        | 200         | 200            | High     |

Also check:

  • Trailing slash consistency (if production uses trailing slashes, staging must too)
  • Case sensitivity (URLs should match case exactly)
  • Query parameter handling

3. SEO element comparison

For all Critical and High tier pages, fetch both production and staging versions with Bash curl (WebFetch summarises the page and can't see <head>, so it misses titles, canonicals and meta robots) and compare:

Title tags:

  • Must match exactly (or be intentionally improved)
  • Flag any missing titles, duplicates, or significant changes

H1 tags:

  • Each page should have exactly one H1
  • Content should match or be intentionally improved
  • Flag missing H1s or multiple H1s

Meta descriptions:

  • Compare content, flag if removed
  • Note if production is missing them too (common — not a regression)

Canonical tags:

  • Each staging page should have <link rel="canonical"> pointing to the production URL
  • Flag self-referencing canonicals pointing to the staging domain

Meta robots:

  • Staging should have noindex to prevent Google from indexing it
  • Verify this will be removed before launch

Heading hierarchy:

  • Compare H1 > H2 > H3 structure
  • Flag skipped heading levels (e.g., H1 directly to H4)

Present as a comparison table per page.

4. Content integrity check

For all Critical and High tier pages, compare:

Text content:

  • Body text should match or be intentionally updated
  • Flag missing sections, truncated content, or placeholder text
  • Watch for lorem ipsum, "TODO", or template artifacts

Contact information:

  • Phone numbers must match exactly
  • Email addresses must match exactly
  • Physical address must match exactly
  • Business hours must match exactly

Pricing and offers:

  • Any pricing displayed must match production exactly
  • Package names, descriptions, and prices
  • Discount percentages, tax deduction info

Images:

  • All production images should be present on staging
  • Flag broken images (src returning 404)
  • Check that alt text is preserved

CTAs and forms:

  • All call-to-action buttons present
  • Button text matches
  • Links point to correct destinations
  • Forms have all required fields

5. Navigation and site structure

Header:

  • Logo links to homepage
  • Menu items match production
  • Dropdown/submenu structure preserved
  • Mobile menu works (check viewport meta tag)

Footer:

  • All footer links present and working
  • Contact information matches
  • Legal links present (privacy policy, terms)
  • Social media links correct

Internal linking:

  • Cross-links between pages preserved
  • No links pointing to staging domain (should use relative paths or production domain)
  • No broken internal links

6. Technical checks

Sitemap:

  • /sitemap.xml exists and is valid
  • Contains all indexable pages
  • No 404 URLs listed
  • URLs use production domain (not staging)

Robots.txt:

  • /robots.txt exists
  • Does not block important resources
  • References sitemap

HTTPS:

  • All pages load over HTTPS
  • No mixed content (HTTP resources on HTTPS page)

Performance (spot check):

  • Staging is not significantly slower than production
  • No large unoptimized images
  • No render-blocking resources missing

Language and locale:

  • <html lang="..."> attribute matches production
  • Character encoding correct (Swedish characters, accents, etc.)

7. Functional testing (manual, browser only)

These need a real browser with JavaScript and interaction; curl and WebFetch can't submit forms or render a consent banner. List them as a checklist for the user (or check them with a browser tool if one is available) and mark each "not tested" in the report rather than passing it:

  • Contact form submits successfully
  • Cookie consent banner appears and functions
  • Phone numbers are clickable (tel: links) on mobile
  • External links open correctly
  • 404 page exists and is helpful

8. Generate the audit report

Present findings as a structured report:

Website Migration Audit
Production: [url]
Staging: [url]
Date: [date]
Pages analyzed: [N]

LAUNCH READINESS: [BLOCKED / READY WITH WARNINGS / READY]

━━━ BLOCKERS (must fix before launch) ━━━

[B1] Missing page: /important-page/
     Traffic: 500 clicks/3mo, avg position 4.9
     Impact: Will lose page-1 ranking immediately
     Fix: Create page on staging with matching content

[B2] ...

━━━ WARNINGS (should fix before launch) ━━━

[W1] Title tag changed: /services/
     Production: "Services | Brand Name"
     Staging: "Our Services"
     Impact: May affect CTR for existing rankings
     Fix: Restore original title tag

[W2] ...

━━━ SEO SCORECARD ━━━

| Check                    | Status | Details                          |
|--------------------------|--------|----------------------------------|
| URL parity               | X/Y OK | [N] pages missing                |
| Title tags               | X/Y OK | [N] changed                      |
| H1 tags                  | X/Y OK | [N] missing or changed           |
| Meta descriptions        | X/Y OK | [N] removed                      |
| Canonical tags           | X/Y OK | [N] missing or wrong             |
| Contact info             | PASS   | All matching                     |
| Pricing                  | PASS   | All matching                     |
| Images                   | X/Y OK | [N] broken                       |
| Internal links           | X/Y OK | [N] broken                       |
| Sitemap                  | PASS   | [N] URLs                         |
| Robots.txt               | PASS   |                                  |
| HTTPS                    | PASS   |                                  |

━━━ PRE-LAUNCH CHECKLIST ━━━

Before switching DNS / going live:
- [ ] All blockers resolved
- [ ] Remove noindex tags from staging
- [ ] Update canonical URLs to production domain
- [ ] Verify sitemap references production URLs
- [ ] Submit updated sitemap to Google Search Console (and Bing Webmaster Tools)
- [ ] Set up 301 redirects for any changed URLs
- [ ] Verify analytics tracking (GA4 / GTM) is installed
- [ ] Take baseline screenshots of top pages in Google Cache

━━━ POST-LAUNCH MONITORING (first 4 weeks) ━━━

Week 1:
- Monitor Search Console for crawl errors daily
- Check indexed page count hasn't dropped
- Verify top pages still appear in search results
- Monitor 404 errors in server logs

Week 2-4:
- Compare click/impression data week-over-week
- Check average position for key pages
- Verify no new crawl issues
- Monitor Core Web Vitals in Search Console

Deeper Analysis with Live Data

If Cogny MCP is connected, this skill automatically enhances the audit with:

Google Search Console / BigQuery: actual traffic data to prioritize pages by real-world SEO impact — clicks, impressions, CTR, and average position.

Bing Webmaster Tools: Bing-specific crawl issues, indexing status, traffic data and inbound links per URL.

Ahrefs / Semrush: pages with backlinks, so link equity gets a redirect even when a page has little search traffic.

CMS (WordPress, Webflow, Ghost, Framer, Sanity, Contentful, Shopify): complete page inventories and existing redirects on both sides of the migration.

Sitemap submission (Google_Search_Console__tool_submit_sitemap, Bing_Webmaster_Tools__tool_submit_feed) and redirect creation are writes. The skill drafts them and asks first.

Connect your accounts via Cogny ($9/mo per channel), then re-run the audit for traffic-weighted prioritization.

For ongoing monitoring after launch, use /seo-monitor.

Frequently asked questions

What does the Website Migration Audit AI skill do?

Compare a production site against a staging/redesign version — SEO parity, content integrity, missing pages, and launch readiness

Why use Website Migration Audit on TypingMind?

Because you install it once and use it with any model. Website Migration Audit is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Website Migration Audit in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/cognyai/claude-code-marketing-skills/tree/main/skills/website-migration-audit. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Website Migration Audit?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Website Migration Audit?

As many as you like. As long as a model supports skills, you can use Website Migration Audit with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Website Migration Audit AI skill free?

It is published on GitHub by cognyai. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇