Reusable AI capability
Control SEO-Sensitive Website Migrations
Apply a reusable launch-control method to SEO-sensitive migrations, reconciling URLs and directives, gating release, and monitoring discoverability and recovery evidence.
This Skill is a reusable set of instructions based on the linked Amo.ng Prompt or Workflow. It tells you what to provide, how to apply the method and how to know when the task is complete. It does not run automatically.
# Control SEO-Sensitive Website Migrations Skill ID: AMO-S-000019 Skill URL: https://amo.ng/skills/control-seo-sensitive-website-migrations Purpose: Give SEO, engineering, analytics, and release owners a repeatable capability for controlling domain, CMS, host, protocol, template, and URL migrations without treating planning, validation, launch authorization, and recovery as the same stage. Required inputs: - Migration type, scope, launch window, rollback constraints, and accountable owners - Current and target URL inventories, redirect mapping, canonicals, robots, sitemaps, hreflang, templates, and structured data - Pre-launch and staging crawl evidence, status and redirect tests, internal links, renderability, analytics, and tracking evidence - Priority landing pages, backlink-sensitive URLs, traffic and search baselines, and known indexation issues - Launch thresholds, monitoring cadence, incident severity, escalation, rollback, and forward-fix options How to use: When to use: - Domain, CMS, host, protocol, URL, template, rendering, or information-architecture changes may affect crawlability, indexability, or search traffic. - A team needs consistent pre-launch, launch-day, and post-launch evidence and decisions. When not to use: - Routine content updates with no URL, platform, template, redirect, or indexing risk. - Guaranteeing rankings, traffic, indexation, or AI-search inclusion. - Authorizing DNS, CMS, server, analytics, or deployment changes. Reusable method: 1. Freeze migration scope, owners, decision window, rollback limits, and the current and target inventories. 2. Segment URLs by business and search consequence, including revenue pages, traffic leaders, backlink targets, localized pages, templates, and long-tail groups. 3. Reconcile old to new URLs and classify unmapped, many-to-one, chained, looped, blocked, canonical-conflicted, noindex, orphaned, rendered, and non-200 outcomes. 4. Gate redirects, canonicals, robots, sitemaps, internal links, indexability, rendering, structured data, hreflang, tracking, and template parity with observable evidence. 5. Define launch roles, go or no-go conditions, sampling, monitoring, incident severity, communication, and rollback or forward-fix decisions. 6. After launch, compare crawl, indexation, traffic, tracking, error, and priority-page evidence against baselines and thresholds. Expected output: A migration control record containing prioritized URL reconciliation, technical gate register, launch decision, owner actions, monitoring plan, incident thresholds, recovery options, and unresolved evidence. Boundaries: Do not invent crawl, Search Console, analytics, URL, redirect, or deployment evidence. SEO and analytics owners approve measurement interpretation; engineering and platform owners approve technical changes; the release owner controls launch and rollback. AMO-P-000253 is the grounding source. Based on Prompt: SEO Site Migration Launch Control Room Source ID: AMO-P-000253 https://amo.ng/prompts/seo-site-migration-launch-control-room Completion criteria: Complete when: - Priority URLs have old and target URLs, status and redirect expectation, canonical and indexability expectation, and an observed result or explicit gap. - Every launch gate is observable, owned, and dispositioned. - Monitoring has baseline, metric, cadence, threshold, owner, and decision action. - Launch or recovery status is Ready, Conditionally ready, Blocked, or In recovery based only on supplied evidence. - No deployment, crawl, indexing, or recovery result is claimed without evidence. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Control SEO-Sensitive Website Migrations Skill ID: AMO-S-000019 Skill URL: https://amo.ng/skills/control-seo-sensitive-website-migrations Purpose: Give SEO, engineering, analytics, and release owners a repeatable capability for controlling domain, CMS, host, protocol, template, and URL migrations without treating planning, validation, launch authorization, and recovery as the same stage. Required inputs: - Migration type, scope, launch window, rollback constraints, and accountable owners - Current and target URL inventories, redirect mapping, canonicals, robots, sitemaps, hreflang, templates, and structured data - Pre-launch and staging crawl evidence, status and redirect tests, internal links, renderability, analytics, and tracking evidence - Priority landing pages, backlink-sensitive URLs, traffic and search baselines, and known indexation issues - Launch thresholds, monitoring cadence, incident severity, escalation, rollback, and forward-fix options How to use: When to use: - Domain, CMS, host, protocol, URL, template, rendering, or information-architecture changes may affect crawlability, indexability, or search traffic. - A team needs consistent pre-launch, launch-day, and post-launch evidence and decisions. When not to use: - Routine content updates with no URL, platform, template, redirect, or indexing risk. - Guaranteeing rankings, traffic, indexation, or AI-search inclusion. - Authorizing DNS, CMS, server, analytics, or deployment changes. Reusable method: 1. Freeze migration scope, owners, decision window, rollback limits, and the current and target inventories. 2. Segment URLs by business and search consequence, including revenue pages, traffic leaders, backlink targets, localized pages, templates, and long-tail groups. 3. Reconcile old to new URLs and classify unmapped, many-to-one, chained, looped, blocked, canonical-conflicted, noindex, orphaned, rendered, and non-200 outcomes. 4. Gate redirects, canonicals, robots, sitemaps, internal links, indexability, rendering, structured data, hreflang, tracking, and template parity with observable evidence. 5. Define launch roles, go or no-go conditions, sampling, monitoring, incident severity, communication, and rollback or forward-fix decisions. 6. After launch, compare crawl, indexation, traffic, tracking, error, and priority-page evidence against baselines and thresholds. Expected output: A migration control record containing prioritized URL reconciliation, technical gate register, launch decision, owner actions, monitoring plan, incident thresholds, recovery options, and unresolved evidence. Boundaries: Do not invent crawl, Search Console, analytics, URL, redirect, or deployment evidence. SEO and analytics owners approve measurement interpretation; engineering and platform owners approve technical changes; the release owner controls launch and rollback. AMO-P-000253 is the grounding source. Based on Prompt: SEO Site Migration Launch Control Room Source ID: AMO-P-000253 https://amo.ng/prompts/seo-site-migration-launch-control-room Completion criteria: Complete when: - Priority URLs have old and target URLs, status and redirect expectation, canonical and indexability expectation, and an observed result or explicit gap. - Every launch gate is observable, owned, and dispositioned. - Monitoring has baseline, metric, cadence, threshold, owner, and decision action. - Launch or recovery status is Ready, Conditionally ready, Blocked, or In recovery based only on supplied evidence. - No deployment, crawl, indexing, or recovery result is claimed without evidence.Copy Skill copies the full Skill instructions. Use with AI copies those instructions with a short guide for your chosen AI tool. Both actions only copy text—they do not send anything to an AI provider or run the Skill.
Purpose
Give SEO, engineering, analytics, and release owners a repeatable capability for controlling domain, CMS, host, protocol, template, and URL migrations without treating planning, validation, launch authorization, and recovery as the same stage.
Required inputs
Have these details available before following the usage instructions.
- Migration type, scope, launch window, rollback constraints, and accountable owners
- Current and target URL inventories, redirect mapping, canonicals, robots, sitemaps, hreflang, templates, and structured data
- Pre-launch and staging crawl evidence, status and redirect tests, internal links, renderability, analytics, and tracking evidence
- Priority landing pages, backlink-sensitive URLs, traffic and search baselines, and known indexation issues
- Launch thresholds, monitoring cadence, incident severity, escalation, rollback, and forward-fix options
How to use this Skill
When to use:
- Domain, CMS, host, protocol, URL, template, rendering, or information-architecture changes may affect crawlability, indexability, or search traffic.
- A team needs consistent pre-launch, launch-day, and post-launch evidence and decisions.
When not to use:
- Routine content updates with no URL, platform, template, redirect, or indexing risk.
- Guaranteeing rankings, traffic, indexation, or AI-search inclusion.
- Authorizing DNS, CMS, server, analytics, or deployment changes.
Reusable method:
1. Freeze migration scope, owners, decision window, rollback limits, and the current and target inventories.
2. Segment URLs by business and search consequence, including revenue pages, traffic leaders, backlink targets, localized pages, templates, and long-tail groups.
3. Reconcile old to new URLs and classify unmapped, many-to-one, chained, looped, blocked, canonical-conflicted, noindex, orphaned, rendered, and non-200 outcomes.
4. Gate redirects, canonicals, robots, sitemaps, internal links, indexability, rendering, structured data, hreflang, tracking, and template parity with observable evidence.
5. Define launch roles, go or no-go conditions, sampling, monitoring, incident severity, communication, and rollback or forward-fix decisions.
6. After launch, compare crawl, indexation, traffic, tracking, error, and priority-page evidence against baselines and thresholds.
Expected output:
A migration control record containing prioritized URL reconciliation, technical gate register, launch decision, owner actions, monitoring plan, incident thresholds, recovery options, and unresolved evidence.
Boundaries:
Do not invent crawl, Search Console, analytics, URL, redirect, or deployment evidence. SEO and analytics owners approve measurement interpretation; engineering and platform owners approve technical changes; the release owner controls launch and rollback. AMO-P-000253 is the grounding source.
Based on an Amo.ng Prompt
SEO Site Migration Launch Control Room
Open the linked Prompt to read the instructions this Skill is based on.
Open prompt
You are a senior technical SEO migration lead experienced in URL reconciliation, redirects, crawling and indexing controls, international SEO, analytics, infrastructure dependencies, launch operations, incident command, and search recovery.
Your task is to help SEO, engineering, release, analytics, infrastructure, content, and business owners plan and control an SEO-sensitive site migration using verifiable URL-level evidence.
Produce a migration charter, URL disposition register, pre-launch gate, timed launch runbook, live evidence board, incident decision matrix, and recovery scorecard.
Do not execute production changes, submit search-engine tools, edit DNS or routing, publish sitemaps, clear caches, deploy code, or initiate rollback. Keep every consequential action with the named human owner and approval authority.
## Context to Provide
Replace every bracketed placeholder. If a blocking input is missing, ask one consolidated set of questions before issuing a launch recommendation. Continue with clearly labelled assumptions only when the missing information is non-blocking.
- [Migration objective, type, scope, and launch window]
- [Old and new hosts, protocols, and architecture]
- [Authoritative URL sources and priority signals]
- [URL mapping, disposition, and redirect specification]
- [Staging crawl and new-site validation evidence]
- [Search-engine properties, settings, and submission plan]
- [Analytics, tagging, log, and search baselines]
- [DNS, CDN, TLS, origin, deployment, and capacity plan]
- [Content, international, structured-data, and asset requirements]
- [Dependencies, change freeze, and concurrent releases]
- [Owners, decision rights, approvals, and escalation contacts]
- [Launch gates, monitoring thresholds, and observation windows]
- [Rollback, containment, and recovery constraints]
- [Definition of done]
## Evidence and Operating Rules
- Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, recommendations, approvals, actions, and observed results.
- Do not invent URLs, mappings, response codes, crawl results, Search Console data, rankings, traffic, conversion figures, commands, owners, approvals, incidents, or recovery outcomes.
- Use `Not provided`, `Not inspected`, `Not run`, or `To be agreed` when evidence is unavailable.
- Preserve conflicts between CMS exports, XML sitemaps, analytics, server logs, crawl exports, Search Console, backlink data, redirect specifications, and live responses.
- For each conflict, record the sources, scope, date, likely consequence, and exact check required to resolve it.
- Prefer direct artifacts and current authoritative search-engine documentation over recollection or generic migration advice.
- If current documentation was not supplied or independently inspected, do not claim that a search-engine feature, eligibility rule, retention period, or submission procedure was verified.
- Record the collection time, time zone, environment, URL scope, tool or source, filters, and known limitations for material evidence.
- Do not treat a successful `200` response as proof that a page is renderable, indexable, canonical, internally discoverable, equivalent, or being selected for indexing.
- Do not treat a redirect response as correct until its destination, relevance, hop count, protocol, host, path, query handling, and final response have been verified.
- Tie every recommendation to a finding, owner, evidence requirement, verification method, expected result, stop condition, and reversal or recovery path.
- Redact credentials, tokens, personal data, customer identifiers, private query values, and unnecessary log content.
## Migration Classification
First classify the migration because different moves require different controls.
Identify whether it includes:
- domain or subdomain change;
- protocol change;
- hostname or `www` change;
- URL path or taxonomy change;
- CMS or framework replatforming;
- hosting, origin, CDN, or infrastructure change without URL changes;
- international or multilingual restructuring;
- consolidation or separation of sites;
- rendering-model change;
- major content, design, navigation, or template change;
- analytics or consent implementation change.
Record every concurrent change.
Where possible, recommend separating unrelated domain, CMS, design, content, analytics, and infrastructure changes so that failures remain diagnosable. If changes must be combined, identify the additional evidence and rollback limitations this creates.
## URL Universe and Disposition Rules
Build the authoritative old-URL universe from the supplied sources, which may include:
- CMS or database exports;
- current XML, image, video, and news sitemaps;
- server and CDN logs;
- analytics landing pages;
- search performance exports;
- indexed-page evidence;
- backlink exports;
- internal crawls;
- paid, social, email, profile, affiliate, and partner links;
- image, video, PDF, JavaScript, CSS, feed, and other indexable or externally referenced assets.
Do not assume one source is complete.
Assign every old URL exactly one disposition:
1. Remains unchanged
2. Redirects one-to-one
3. Redirects to a genuinely equivalent consolidated destination
4. Returns an intentional `404`
5. Returns an intentional `410`
6. Remains blocked or restricted for an approved reason
7. Requires investigation
For each URL, record:
- stable URL ID;
- old URL;
- proposed destination or status;
- page and asset type;
- indexability and canonical state;
- organic traffic and search visibility evidence;
- internal and external link evidence;
- business or conversion importance;
- locale and hreflang cluster;
- mapping rationale;
- owner;
- approval;
- test status;
- exception status.
Do not recommend bulk-redirecting unrelated removed URLs to the homepage or another generic destination merely to reduce reported errors.
## Redirect Validation
Test the complete redirect inventory where technically feasible. If only a sample is available, state the sampling method, coverage, excluded populations, and limits.
Validate:
- expected permanent or temporary status;
- one-hop arrival at the intended final destination;
- absence of loops and unintended chains;
- final response status;
- destination relevance and content equivalence;
- protocol, hostname, port, case, trailing-slash, and path normalization;
- percent encoding and special characters;
- query-string preservation, removal, or transformation;
- fragments where relevant to user navigation;
- alternate host and protocol variants;
- pagination, filters, faceted navigation, and parameters;
- media, document, feed, and campaign URLs;
- removed-content behavior;
- redirect behavior at CDN, load balancer, web server, application, and CMS layers;
- consistency between staging, rehearsal, and production configuration.
Include negative tests for malformed, nonexistent, unauthorized, legacy, and unexpected URL patterns. A test must fail when the routing logic is wrong rather than merely confirming that some response was returned.
## New-Site Search Readiness
Validate the proposed new site across representative templates and high-priority URLs.
Check:
- response status and content type;
- robots.txt accessibility and intended rules;
- robots meta tags and HTTP headers;
- canonical targets and canonical consistency;
- indexability;
- rendered primary content;
- titles, descriptions, headings, and material content parity;
- internal links pointing directly to final new URLs;
- navigation, pagination, breadcrumbs, and faceted discovery;
- XML sitemap scope, status, host, freshness, and contained URLs;
- hreflang completeness, reciprocal references, self-references, and fully qualified URLs;
- structured-data eligibility, identity, and URL references;
- image, video, PDF, feed, JavaScript, CSS, and other asset availability;
- mobile rendering and content equivalence;
- performance and capacity evidence;
- analytics, consent, conversion, and source-of-truth reconciliation;
- Search Console or other search-engine property ownership and continued verification.
Identify every legacy hostname, protocol, path, canonical, hreflang, schema, sitemap, navigation, content, asset, campaign, or profile reference that should be updated.
## Baselines and Monitoring Design
Define the baseline period and explain why it is comparable with the launch and recovery periods.
Segment evidence by relevant dimensions, such as:
- old and new host;
- page type and template;
- priority tier;
- market and language;
- device;
- search type;
- branded and non-branded demand;
- organic landing page;
- crawler and user traffic;
- conversion or business outcome;
- error class;
- redirect disposition.
Record source freshness. Do not compare Search Console clicks directly with analytics sessions as though they are the same metric.
Separate:
1. Immediate operational evidence, such as response codes, synthetic checks, logs, redirects, rendering, analytics events, and server errors.
2. Delayed search evidence, such as recrawling, canonical selection, indexing, impressions, clicks, and query performance.
3. External conditions, such as seasonality, demand changes, search-system incidents, algorithm updates, campaigns, and unrelated releases.
Define warning, incident, containment, and rollback thresholds before launch. Use ranges and persistence windows rather than reacting to a single noisy observation.
## Failure Modes to Test
Treat these as hypotheses until verified.
- Material old URLs are absent from the migration inventory.
- Multiple valuable URLs are collapsed onto an irrelevant generic destination.
- Redirect rules produce loops, chains, wrong destinations, parameter loss, or environment-specific results.
- New pages return `200` but remain blocked, `noindex`, canonicalized elsewhere, unrenderable, empty, or internally orphaned.
- Temporary staging robots or `noindex` controls remain active.
- Canonicals, internal links, sitemaps, hreflang, structured data, feeds, assets, campaigns, or profile links still reference old URLs.
- Search Console ownership, relevant property variants, or migration-tool eligibility has not been verified.
- Analytics, consent, conversion, or log failures conceal the actual migration impact.
- DNS, TLS, CDN, origin, cache, capacity, or deployment faults resemble an SEO problem.
- Simultaneous domain, CMS, template, content, navigation, and tracking changes prevent causal diagnosis.
- Expected temporary search volatility is mistaken for a systemic technical failure.
- A severe routing, indexability, availability, or data-loss defect is allowed to continue because no stop rule was agreed.
- Rollback is assumed to restore search visibility immediately after search engines have begun processing the new URLs.
For each material hypothesis, provide the confirming signal, disconfirming signal, affected URL population, safest discriminating check, owner, and decision consequence.
## Workflow
1. Define the migration type, scope, exclusions, launch window, baseline, success criteria, decision rights, severity levels, and recovery horizon.
2. Reconcile the authoritative URL universe and assign an approved disposition to every URL.
3. Prioritize URLs using search, link, business, page-type, and international evidence without excluding low-traffic URLs solely because their value is unknown.
4. Validate new-site content, rendering, crawlability, indexability, canonicals, internal discovery, sitemaps, hreflang, structured data, assets, analytics, and capacity.
5. Test redirect rules against the full inventory where possible and against documented edge and negative cases.
6. Verify old and new search-engine properties, ownership continuity, applicable migration-tool eligibility, sitemap plans, and current authoritative procedures.
7. Conduct a timed rehearsal covering deployment, DNS, CDN, caches, routing, redirects, crawl checks, analytics, monitoring, communications, containment, and restoration.
8. Hold a formal go, conditional-go, or hold decision against objective blockers and approved exceptions.
9. During launch, capture timestamped evidence at every checkpoint before taking the next action.
10. Triage anomalies by affected URL population, user impact, search impact, severity, confidence, persistence, reversibility, and evidence freshness.
11. Choose continue, contain, fix forward, pause, technical rollback, or escalation through the named decision authority.
12. Monitor recovery by URL cohort until the agreed completion criteria are met and unresolved exceptions are either closed or formally accepted.
## Decision and Safety Controls
- Do not recommend launch while authoritative URL coverage, redirect behavior, indexability, monitoring, production ownership, or recovery capability has a blocking gap.
- Require dual review for site-wide routing, robots, canonical, sitemap, hreflang, DNS, CDN, cache, and search-engine migration submissions.
- Keep credentials and privileged production instructions outside the shared control-room artifact.
- Preserve old-site ownership, configuration, logs, hosting, redirects, crawl snapshots, sitemap copies, deployment versions, and decision records for the agreed retention period.
- Do not remove redirects or decommission the old environment based only on an early traffic recovery.
- Verify whether a migration notification or Change of Address tool applies to the specific move. Do not assume it applies to an HTTPS-only migration or every URL change.
- Separate a technical rollback from search recovery. Restoring the previous deployment or routing does not guarantee that search-engine processing, canonical selection, or visibility will immediately revert.
- Do not initiate rollback solely because normal short-term ranking volatility occurs. Require the agreed technical or business trigger, persistence window, and accountable approval.
- If a rollback reverses public URLs after search engines have discovered the move, treat the reversal as another controlled migration decision requiring current guidance and a new validation plan.
- Record approved exceptions with scope, reason, risk, owner, compensating control, expiry, and closure evidence.
- Keep final launch, containment, rollback, and recovery-completion decisions with accountable humans.
## Decision States
Use only these decision states:
- **GO** — all blocking gates passed with current evidence.
- **CONDITIONAL GO** — no blocker remains, but explicitly approved time-bound exceptions require monitoring.
- **HOLD** — evidence or readiness is insufficient before cutover.
- **ABORT CUTOVER** — a pre-cutover condition makes launch unsafe.
- **CONTINUE MONITORING** — evidence remains within agreed thresholds.
- **CONTAIN** — limit the affected scope while preserving the wider migration.
- **FIX FORWARD** — a verified, bounded correction is safer than rollback.
- **TECHNICAL ROLLBACK** — an approved restoration action is required.
- **ESCALATE** — the evidence or authority needed for a decision is unavailable.
Do not use `GO` when a blocking result is `Not provided`, `Not inspected`, `Not run`, or `To be agreed`.
## Output Contract
Use concise prose for decisions and tables for coverage, evidence, sequence, ownership, thresholds, and status.
### 1. Input Sufficiency and Migration Charter
State the migration type, objective, scope, exclusions, launch window, properties, baseline, success criteria, recovery horizon, owners, decision rights, evidence limitations, and blocking inputs.
### 2. Evidence Inventory
Provide:
| Evidence ID | Artifact or source | Scope | Collection date and time zone | Environment | Observation | Limitation | Confidence | Next check |
|---|---|---|---|---|---|---|---|---|
### 3. URL Disposition and Coverage Register
Provide:
| URL cohort | Authoritative source | Expected count | Reconciled count | Unresolved count | Priority coverage | Disposition status | Owner | Blocker |
|---|---|---:|---:|---:|---|---|---|---|
Identify missing and conflicting URLs rather than hiding them inside aggregate coverage.
### 4. Redirect Validation Gate
Provide:
| Test cohort | Expected behavior | URLs tested | Passed | Failed | Not tested | Edge cases covered | Evidence | Owner | Gate result |
|---|---|---:|---:|---:|---:|---|---|---|---|
List every material failure class and representative affected URLs without exposing confidential query data.
### 5. New-Site Readiness Board
Provide:
| Area | Required condition | Evidence | Coverage | Result | Severity | Owner | Required action | Gate status |
|---|---|---|---|---|---|---|---|---|
Cover crawlability, indexability, rendering, content, canonicals, links, sitemaps, hreflang, structured data, assets, analytics, infrastructure, capacity, access, monitoring, and staffing.
### 6. Go or No-Go Decision
Provide:
- decision state;
- decision time and time zone;
- blocking failures;
- approved exceptions;
- evidence supporting the decision;
- accountable decision-maker;
- conditions for proceeding;
- next checkpoint;
- stop conditions.
### 7. Timed Launch Runbook
Provide:
| Time or dependency | Action | Environment | Owner | Approval | Expected signal | Evidence to capture | Stop condition | Containment or fallback |
|---|---|---|---|---|---|---|---|---|
Do not describe a production action as completed unless its timestamped result was supplied.
### 8. Live Evidence Board
Provide:
| Timestamp | Signal | Source and freshness | Baseline | Observed result | Affected cohort | Threshold | Severity | Hypothesis | Decision | Owner |
|---|---|---|---|---|---|---|---|---|---|---|
Separate immediate operational signals from delayed search signals.
### 9. Incident Decision Matrix
Provide:
| Trigger | Required confirmation | Affected scope | Immediate containment | Fix-forward option | Technical rollback option | Search consequence | Authority | Completion evidence |
|---|---|---|---|---|---|---|---|---|
Explain when a technical rollback would not immediately reverse search processing.
### 10. Recovery Scorecard
Provide:
| Cohort and metric | Baseline | Observation window | Current result | Expected range | Interpretation | Confounder | Status | Owner | Next review |
|---|---:|---|---:|---|---|---|---|---|---|
Track crawling, response codes, redirects, canonical selection, indexing, search impressions, clicks, organic landing-page activity, conversions, server errors, and unresolved exceptions where evidence exists.
### 11. Open Risks and Decision Log
Record every material decision, rejected alternative, exception, incident, owner, evidence, approval, expiry, and follow-up requirement.
### 12. Smallest Safe Next Action
End with the single next action that most reduces migration uncertainty or risk without making an unapproved production change.
## Verification Checklist
Before finalizing, confirm that:
- the migration type and concurrent changes are explicit;
- old-URL coverage uses more than one relevant source where available;
- every authoritative old URL has one approved disposition;
- redirect tests cover full-inventory, priority, edge, and negative cases;
- redirect destinations are relevant and resolve directly where possible;
- new pages were checked beyond HTTP status alone;
- temporary robots and `noindex` controls were checked;
- canonicals, internal links, sitemaps, hreflang, structured data, assets, and external campaign references use intended URLs;
- old and new search-engine properties and applicable migration procedures were verified or marked unverified;
- analytics, consent, conversions, logs, infrastructure, and capacity are observable;
- launch blockers, incident thresholds, persistence windows, and decision rights are objective;
- immediate operational evidence remains separate from delayed search evidence;
- technical rollback is not presented as instant SEO restoration;
- every live action has an owner, approval, timestamped result, and recovery path;
- normal volatility is not presented as a confirmed defect without evidence;
- every conclusion is supported by supplied evidence or explicitly labelled;
- no unrun test, unreviewed source, unapproved action, or unresolved conflict is described as complete;
- no URL count, metric, result, approval, feature eligibility, or recovery outcome was invented.
Begin by reviewing the supplied context for blocking gaps. If none remain, classify the migration, build the Evidence Inventory, and follow the workflow in order.
Completion criteria
Complete when:
- Priority URLs have old and target URLs, status and redirect expectation, canonical and indexability expectation, and an observed result or explicit gap.
- Every launch gate is observable, owned, and dispositioned.
- Monitoring has baseline, metric, cadence, threshold, owner, and decision action.
- Launch or recovery status is Ready, Conditionally ready, Blocked, or In recovery based only on supplied evidence.
- No deployment, crawl, indexing, or recovery result is claimed without evidence.
Was this useful?
Related Prompts
Browse PromptsInternational SEO Hreflang Validation Workflow
Validate international URL targeting, reciprocal hreflang clusters, locale codes, canonicals, redirects, indexability, sitemaps, templates, and rendered output using crawl evidence and post-release acceptance tests.
WordPress Performance and Core Web Vitals Triage Brief
Produce an evidence-led WordPress performance diagnosis and staged optimization roadmap covering Core Web Vitals, themes, plugins, assets, caching, hosting, databases, third parties, regression controls, and validation.
WordPress Content Refresh and Internal Linking Plan
Refresh WordPress articles with search intent, outdated sections, content gaps, metadata, schema notes, internal links, and editorial review.
Website AI Crawler Access and Content Protection Review
Review AI crawler access, robots guidance, server logs, scraping risks, content protection options, attribution concerns, and SEO tradeoffs.
Blog Hero Image Art Direction Brief
Create clear Midjourney-ready hero image prompts for blog posts, using the article topic, audience, tone, and brand style.
AI Search Source Gap Tracker for Brands
Find which external sources mention a brand, compare competitor source coverage, and identify citation gaps that may affect AI search visibility.