Jardine Studio
SERVICE / SEO MIGRATION + REDESIGN SEO

Rebuild the site. Protect the search foundations.

Jardine Studio plans, ships, and monitors the SEO side of a website rebuild: audit, redirect map, schema preservation, launch QA, and Search Console watch. The SEO work shapes the new site before launch instead of cleaning it up after.

Request a migration consultationSee shipped work

Migration discipline that shipped with the work, not after it.

Lambert retained fourteen established product categories while its catalogue was rebuilt into a thirteen-page system. Bodie moved from Ecwid to Shopify with a new shop subdomain and zero merchant downtime. Together they show continuity inside a full rebuild and a focused platform handoff. Click through for the full case write-ups. More on the case studies index. Most of this work lands with B2B, hospitality, wellness, trades and local service, and nonprofit and heritage businesses in and around Toronto.

Six pillars cover most engagements, scoped to the size of the rebuild.

Every migration pulls from these six pillars. Small migrations might run only two or three. Larger rebuilds use all six and add depth to each. The mix gets shaped after the audit, around what the site has at stake and what the rebuild is changing. For a head start on that baseline, the free SEO Audit crawls up to 25 pages and flags indexing, canonical, and structure issues to carry into the redirect map. A technical audit before a migration shows what to fix first.

  • Pre-launch audit and inventory

    Combine the CMS, sitemaps, crawl results, and available Search Console, analytics, and backlink evidence into a URL inventory. Record business importance, traffic, conversions, and any documented citations where those sources are available. Give each known URL a keep, move, merge, or retire decision before implementation.

  • Redirect map

    One-to-one URL mapping in a format the dev team can implement and the studio can verify. No funnel-everything-to-home anti-patterns. No 302s where 301s belong. Tested with Screaming Frog or an equivalent crawler before launch, then again after, with every chain resolved to a single hop.

  • Content and metadata preservation

    Titles, meta descriptions, H1s, alt text, internal anchor text, and on-page links migrated and diffed against the old site. The pages Google was rewarding stay structurally the same where they need to stay the same. Improvements happen on purpose, not by accident in a template rewrite.

  • Technical migration

    Check canonicals, sitemaps, robots directives, structured data, hreflang where applicable, and image, font, and rendering behavior. Confirm that intended public pages are accessible and eligible for indexing. Search engines determine whether and when they index those pages; the implementation cannot guarantee that timing.

  • Launch-day QA

    Day-of checklist: crawl the new site, validate the redirect chain, validate schema, validate sitemap submission, run Search Console change-of-address if applicable, confirm GBP and directory entries point at the new URLs. The studio does the QA, not a third party.

  • Post-launch monitoring

    Search Console daily for the first month, weekly for the next two. Ranking checks on the top URLs. 404 monitoring. AI citation tracking. Soft fixes ship the same week they are caught. A retainer is available for the months after launch; it is not required.

Check the failure scenarios before and after launch.

These are failure scenarios to test during a migration, not a prediction that every rebuild will lose traffic. A before-and-after comparison shows which changes need correction and which were intentional.

  • The redirect map and the deployed rules disagree.

    A moved page can return a 404, take several redirect hops, or send visitors to an unrelated homepage when the mapping is implemented incorrectly. Compare each old URL with its intended destination and test the deployed response. Use a permanent redirect for a permanent move, and keep useful destinations specific to the original content.

  • The metadata never gets diffed against the old site.

    A template change can replace useful titles, headings, descriptions, image alternatives, or internal links without an explicit content decision. Compare the old and new output for important pages. Preserve what remains useful and document intentional changes so a later performance review has a reliable baseline.

  • Structured data no longer matches the page.

    Changing templates can remove valid markup or leave old URLs, business details, and entity references behind. Inspect the rendered structured data, confirm that it describes the visible content, and validate the relevant types and relationships. Correct markup supports understanding and eligibility for applicable features; it does not guarantee a search appearance.

  • Changed URLs are missing from the search baseline.

    If a page appears in a generated answer before the move, record the cited URL, prompt, platform, date, and test conditions. Recheck the destination and observed answers after launch. Generated answers can vary between checks; a changed citation alone does not establish that the migration caused it or predict whether it will return.

  • The Google Business Profile keeps pointing at the old URL.

    A profile or directory link can keep sending visitors through an old URL or a broken booking path after a move. Update the links the business controls and test their final destinations on mobile. This is a continuity check; the presence of a redirect alone does not establish a local-ranking penalty.

  • The staging robots file makes it to production.

    A staging disallow rule can block crawling if copied to production. A noindex directive can exclude a page from search once processed. Inspect production robots.txt, response headers, page directives, and canonicals before and after launch. These controls have different effects, so test the actual response rather than assuming a staging setting was removed.

Assess the migration risk against your existing traffic.

The useful questions are which pages support the business, what is changing, and how problems will be detected and corrected. A migration plan makes those decisions explicit. For the rebuild budget that can sit alongside this work, the website cost calculator gives a grounded range for design, build, and SEO.

  • Search traffic can fluctuate while changed pages are processed.

    Google advises expecting temporary ranking fluctuations during a site move. The extent and duration depend on the changes and how the pages are recrawled and reindexed. Compare affected pages with a dated baseline, check technical failures separately, and avoid treating every movement as a migration defect. A universal traffic-loss percentage would not describe your site reliably.

  • An inquiry gap can change the acquisition plan.

    If qualified organic inquiries decline, the business may consider paid campaigns or other channels. That decision depends on lead quality, capacity, margins, and acquisition costs. Track accepted inquiries separately from clicks before deciding whether extra spend is warranted.

  • Missing evidence makes changes harder to interpret.

    Without a record of important pages, search performance, and observed citations, a team cannot make a sound before-and-after comparison. Preserve available evidence before launch and state what was not measured. Google uses its existing search requirements for AI features; there is no separate schema requirement or guaranteed citation outcome.

  • Unplanned investigation and repair work.

    When a live defect has no clear owner or record of the intended change, diagnosis can add work to the launch. A versioned redirect map, before-and-after crawl, change log, and named response owner make that investigation more focused. Repair cost and recovery time depend on the defect; neither can be promised in advance.

Planning references: Google's site-move guidance, AI features and website eligibility, and Business Profile ranking factors. Reviewed September 9, 2026. These explain platform guidance, not a forecast for an individual migration.

Who owns the migration plan and launch checks?

A migration can involve one team or several. What matters is that every recommendation has an implementation owner, an acceptance check, and a person responsible for the deployed result. The written scope should make those responsibilities visible.

The redirect map, content decisions, technical checks, and monitoring plan belong in the same release process. Each change needs an expected result that can be checked in production. A shared checklist and a recorded handoff help separate an implementation defect from an unresolved content or business decision.

Jardine Studio runs both inside one engagement. The same hands writing the new pages are writing the redirect rules. The same person watching Lighthouse is watching Search Console. When another team owns the build, the studio agrees the implementation and verification responsibilities with them. More on the model at /about.

Same studio for design, build, and SEO. The migration shapes the rebuild before launch, not after.

The platform is the second decision, not the first.

The migration plan starts with the current platform, available access, content, integrations, and the business requirements for the destination. Export limits and implementation options are checked before scope. The platform list below describes systems the studio can assess, not a claim of a published migration case on every one.

The Bodie Foundation case shows a focused platform migration: Ecwid to Shopify, a new shop subdomain at shop.bodiefoundation.org, DNS through GoDaddy, SSL provisioned globally before the CNAME flip, zero merchant downtime, four hours billed. The migration ran cleanly because every step was sequenced before the cutover, not improvised on the way out. Platform rebuilds without an SEO migration angle live on /services/web-design. The two engagements often run together. Moving from Squarespace? The Squarespace exit inventory helps you collect content and decide what happens to booking, your domain and email before the migration is scoped.

  • Squarespace
  • Wix
  • WordPress
  • Webflow
  • Framer
  • Shopify
  • Ecwid
  • Custom Next.js
  • Custom React
  • Headless CMS (Sanity, Contentful, Notion-backed)

Questions about an SEO migration.

Migration work sits between SEO, design, and development. When it runs inside a website redesign, the redirect map, templates, metadata, and design system ship together. The questions below cover ownership, timing, risk, and what happens after launch.

Can you help with SEO during a website rebuild?
Yes. A rebuild is one of the most important times to involve SEO. Without SEO planning, a new site can lose valuable rankings, traffic, links, and search equity very quickly. We map existing pages, identify what is already performing, plan redirects, preserve useful content, improve weak pages, and launch the new site with a cleaner structure than the one it replaces.
Can you do the rebuild and the SEO migration in one engagement, or only one of them?
Both, and the integrated version is usually the point. The same studio that writes the new pages writes the redirect rules that protect the old ones. Some clients hire only the SEO migration alongside an existing rebuild team; that works too, but the work is stronger when design, development, and SEO live in the same engagement.
What if my site has thousands of URLs?
We combine the CMS, sitemaps, crawl results, and available Search Console, analytics, and backlink records into a URL inventory. Important pages get individual review based on business value and available evidence. Repeated page types can share implementation rules, but each known URL still needs a deliberate keep, move, merge, or retire decision. Observed AI citations can be recorded where available; there is no complete citation inventory promised for every URL.
What if the team that built the old site is gone?
Common, and not a blocker. The studio works from what is currently in production plus whatever access the team can hand over. Search Console, GA4, the CMS admin, the hosting account, and the DNS provider are what matter. The original dev team is not required.
My rebuild is already live and the rankings dropped. Can you help?
Yes. The first step is to compare the old and new site and the available search baseline. The review checks redirects, useful content, metadata, crawl and index directives, canonicals, and other changed implementation details. It also considers timing and changes in demand before attributing the drop to a technical defect. The next scope follows the evidence; recovery is not guaranteed.
How long does an SEO migration take?
Three to twelve weeks, depending on the size of the rebuild and how much overlap there is with the design and development work. A small platform move can run in days. A multi-page rebuild with hundreds of indexable URLs runs alongside the rebuild for two to three months.
Do you guarantee no traffic loss?
No. Google advises expecting temporary ranking fluctuations during a site move while changed URLs are recrawled and reindexed. That does not mean every rebuild loses traffic. We plan redirects, preserve useful content, check the deployed site, and monitor the agreed baseline. We cannot guarantee a traffic level, recovery date, or AI citation.
Do you send the redirect map to my dev team, or implement it yourselves?
Both are possible. When the studio is also doing the rebuild, the redirects ship with the build. When the studio is running the SEO migration alongside an existing rebuild team, the map gets written in the format that team needs and the studio QAs the implementation before launch.
Will my Google Business Profile, AI search citations, and directory listings update automatically?
Update the Business Profile and directory links you control, then test that they reach the intended pages. Generated AI answers are controlled by their platforms and can change between checks. We can record observed citations, check that cited URLs still resolve, and review the accuracy and accessibility of the content. We cannot directly edit those answers or guarantee that a citation updates or remains.
What does an SEO migration engagement cost?
Project-scoped, not packaged. A small platform move on a hosted CMS can run in the low thousands. A multi-page rebuild with a full SEO migration runs into a larger project budget. The studio publishes ranges before the call on the pricing page. The actual number gets quoted after a brief and a 30-minute call.
Do you keep working on the site after launch?
By the month, by choice, not by contract. The first month after launch is included: Search Console checks, 404 monitoring, ranking checks, AI citation watch, and fixes for anything that surfaces. A retainer is available for the months that follow, scoped to what the site needs.
Can you handle a domain migration, not just a redesign on the same domain?
Yes. A domain change adds coordination for DNS, TLS, email, brand references, and the old and new Search Console properties. We use the Change of Address tool where Google's guidance calls for it, alongside permanent redirects and updated internal links and sitemaps. The launch and monitoring plan follows the actual URL and infrastructure changes.

Rebuild planned. Rankings at risk. Same studio for both.

A focused review identifies what the rebuild puts at risk and what the migration would take to ship. Tell us what is moving and what is stuck. We reply within one business day.

Request a migration consultationSee shipped work