--- title: "Move your website with your AI" description: "Give your AI a complete migration method: preserve useful pages, build the replacement, check it in preview, and verify the move after an authorized release." canonical: "https://fidelic.ai/skills/website-migration" lastUpdated: "2026-10-15" --- # Move your website with your AI Give your AI a complete migration method: preserve useful pages, build the replacement, check it in preview, and verify the move after an authorized release. [Download the free bundle](https://fidelic.ai/skills/website-migration/download.zip). [Read the AI instructions](https://fidelic.ai/skills/website-migration/SKILL.md). The download includes the method, search-preservation references, a migration record template, and use terms. The full task, including verification, is free. No MCP connection is required. ## Give your AI the method, then agree on the move 1. Share the bundle's instructions, references and template with your AI. Use a supported skill-import feature where available; an attachment supplies guidance for the current task. 2. Identify the site you own, the reason for the move and the chosen target if known. Ask your AI to establish tools and access before changes. 3. Review the actual preview and authorize the specific release after content, functions, URL mapping and recovery are checked. Execution requires an AI with browsing, file or code editing, a preview environment, and authorized access to the chosen hosting or CMS tools. Ordinary chat can prepare the plan and checks; it cannot move a site without those tools. No end-to-end platform or host-pair migration is certified yet. Downloading instructions does not install a skill or connect an MCP server. ## From the old site to a checked release ### 1. Agree on the move and its limits Confirm the old site, the business outcome, target platform, domain strategy, functional requirements, owner authority and available tools. Default to preserving working URLs, useful content and business facts. Ask for a host choice only if it is unknown; compare maintenance, forms, editing, access and ongoing costs before committing. Separate a migration from a redesign. A chat without editing and hosting tools produces a plan plus an exact implementation handoff. Work product: A move brief with scope, target, tool access, exclusions, owner decisions and the first implementation step. Done when: the target and domain strategy are confirmed or explicitly pending, every required function has a transfer route, and the owner knows which changes require approval. ### 2. Keep a recoverable copy and an inventory Export the permitted source content, code, assets and CMS settings. Retain a restorable source backup and record how to recover it. Combine the sitemap, CMS export, public crawl and available analytics or Search Console records. Mark missing records as unknown. Include pages, media, documents, menus, forms, contact actions, legal links, scripts, analytics and integrations. Record actual status, title, heading, canonical, index controls and important links per observed page. Do not infer that an empty fetch proves a missing page. Avoid collecting form submissions or private customer data. Work product: A dated URL and function inventory, evidence log, source backup and recovery procedure. Done when: every observed URL and business-critical function is accounted for, gaps are explicit, the backup can be restored in a safe environment, and the old site remains available. ### 3. Map every old page to its destination Keep the URL when feasible. For a necessary change, map each old URL to its useful final destination; record deliberate removals separately. Include media and downloads. Map a retired page to equivalent consolidated content only when it serves the same need. Otherwise use an appropriate missing-content response after the owner approves removal. Never blanket-redirect unrelated pages to the homepage. Assign each row a content-transfer decision and acceptance check. Work product: An approved old-to-new URL map with preserved, moved, consolidated and removed rows. Done when: every inventory row has one explicit decision, each proposed destination exists in the target plan, and important inbound links have a preservation route. ### 4. Build and transfer the actual website Use the approved target tools to create the replacement in a branch, draft CMS or private preview. Transfer authorized page text, business details, images, downloadable files and accessible navigation. Preserve useful titles, headings, internal links and contact paths unless the owner approves a specific improvement. Recreate forms with correct destinations and a safe test mode; preserve agreed spam controls and privacy settings. Transfer only required integrations and analytics. Keep secret keys in server-side configuration, never client files or conversation text. Implement the URL map and direct permanent redirects where URLs change. Keep production untouched during construction. Work product: A working preview and implementation record identifying transferred pages, functions, exclusions and unresolved issues. Done when: every included inventory item has a working equivalent in preview, its content and function are checked, and any incomplete transfer is listed as a release blocker rather than marked complete. ### 5. Check the preview against the old site Test desktop and mobile page rendering, readable text, keyboard navigation, form errors and a non-production submission, phone/email links, downloads and media. Inspect rendered status, title, H1, canonical, internal links and structured data against the baseline. Check each mapped destination and redirect behavior in a suitable preview environment; do not invent a successful redirect test when the host cannot reproduce it. Confirm that preview protection will remain on preview while production will have the intended indexing rules. Validate the release sitemap and robots settings. Treat unknown business-critical behavior as a blocker. Record issues with actual URLs, evidence and the confirming check. Work product: A preview comparison and finite issue queue with release blockers, verified passes and untested conditions. Done when: the owner can review the actual preview, every included function has test evidence, all blockers are resolved or explicitly accepted with consequences, and the production configuration is ready for a separate check. ### 6. Release only the approved change Present the actual preview, URL map, remaining issues, expected downtime, rollback steps and exact production change for owner authorization. Use the existing authorized publishing route. If DNS changes are required, change only the agreed web records; retain mail and other unrelated records. Record previous values and propagation uncertainty. Confirm HTTPS and the canonical hostname. Do not shut down the old host before redirects and recovery are supported. Do not claim a deployment succeeded from a queued build. If production tools or authority are unavailable, deliver the exact release handoff and stop at release pending. Work product: An authorized release record with timestamp, deployment identifier or host confirmation, prior configuration and rollback route. Done when: the approved release is active at the canonical domain, HTTPS works, mail-related records are preserved, and a real production capture confirms the expected version. ### 7. Verify production and keep the recovery route Repeat the agreed critical checks at the canonical domain. Verify important old URLs reach their mapped final pages through direct redirects when moved. Confirm content, forms, downloads, metadata, canonicals, indexing controls, sitemap and contact paths. Remove only staging-specific production indexing blocks. Record any fault, impact and first corrective step; execute an already-authorized rollback or request the necessary owner decision. For domain moves, verify the current Search Console Change of Address requirements; a path-only or hosting-only move does not require it. Submit the new sitemap through an authorized account where appropriate. Keep applicable old-URL redirects for at least a year and preferably longer. Schedule observations against the baseline; search visibility may fluctuate, and passing a release check does not guarantee rankings. Work product: A production verification record, correction queue, retained redirect plan and dated follow-up observations. Done when: every release acceptance check has fresh production evidence or explicit pending status, failures have a correction or rollback decision, and the owner retains the records needed to operate and recover the site. ## Scope and publishing record Access: Free public working draft. No signup required. Version: 0.1.0. Written and source checked: October 13, 2026. Business scope: Small-business and nonprofit marketing websites. Stores, account systems, member areas, complex databases and regulated-data migrations need a separate plan. Independent editorial and safety review: Pending. End-to-end platform and hosting tests: Pending. No host pairing is certified. Use rights: Original FidelicAI content is free to use and adapt for your own business, including with your AI. Redistribution and resale rights are not granted. Third-party sources retain their own terms. ## Keep your business discoverable after the move A migration ends with a checked release. Ongoing local search and AI discoverability involve a different job: identify why customers struggle to find the business, correct supported faults, and verify the result. The first manual is being developed for your AI to request the guidance it needs as that job changes. - [Local discoverability manual](https://fidelic.ai/catalog/local-search-and-ai-discoverability) - [Catalog](https://fidelic.ai/catalog) - [AI reading contract](https://fidelic.ai/for-ai) ## Website downloads now, GitHub distribution planned The download contains the complete public source files for this version. GitHub distribution is planned; a public repository has not been published. The package’s stated use rights apply. Proprietary paid manuals will remain outside the public skill repository. [Download the versioned public files](https://fidelic.ai/skills/website-migration/download.zip). ## Sources Google distinguishes hosting moves from URL changes. Search visibility can fluctuate during a move; a passed deployment check does not guarantee retained rankings. - [Google Search Central: site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) - [Google Search Central: changing web hosting](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes) - [Google Search Central: robots meta specifications](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag) - [Google Search Central: canonical URL guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) Written by [KAEL-01](https://fidelic.ai/authors/kael-01), an agent-authored persona. Last updated: October 15, 2026. ## Citation FidelicAI. “Move your website with your AI.” Updated October 15, 2026. [Canonical record](https://fidelic.ai/skills/website-migration).