Skip to main content
    Proof
    Impress Blinds — cost per recorded Google Ads conversion down 62.63%SLS Solicitors — cost per recorded Google Ads conversion down 58.48%FixCare Property — cost per enquiry down 56.36%Rubbish Removal WA — cost per enquiry down 53.18%Floral Cakery — cost per enquiry down 49.82%ILLUMINATE Laser Emporium — cost per enquiry down 48.54%Aussie Plumbing — cost per enquiry down 41.96%Sydney Fence Painting — cost per enquiry down 33.68%Alliance Plumbing — cost per enquiry down 29.6%Gridless Build Solutions — cost per enquiry down 29.16%FacilityWorx — cost per enquiry down 23.62%Cornerstone Roofing — cost per enquiry down 20.47%Council finance — budgeting and workforce designCouncil planning — clearer approvals and reportingCultural audiences — media strategy and creative conceptsCommunity participation — surveys, maps and project pagesPublic-sector research — survey design and analysisPublic art — site studies and visual conceptsRegional identity — visitor guides and wayfinding conceptsCouncil systems — integration and migration planningA pressure washing business — service-led search campaignsA pressure washing business — a clear enquiry journeyA carpet cleaner — Google Ads built around cleaning servicesA roofing company — campaigns for repairs and restorationA CCTV installer — campaigns for security enquiriesA fence painter — search campaigns for specific surfacesA maintenance business — live in 8 weeks, 3 stacks gone41 numbered clauses, published in full5.0 across every Google review$120M+ in media under management250+ active engagements across five countries

    SEO migration Move the site. Keep the rankings.

    A redesign, a replatform, a domain change or a move off WordPress is a migration whether anyone calls it one or not. An SEO migration carries the URLs, the titles and the rankings across.

    250+ live client engagements · Melbourne-based, working across Australia, the UK, the UAE, Saudi Arabia and New Zealand

    Client case studies

    Inside Boutique Home Centre’s website rebuild.

    We rebuilt this Melbourne tile and bathware store on Shopify, with product descriptions, AI-assisted imagery, a room visualiser and connected catalogue workflows. Open the full story to see the work.

    Showing 1 of 1 client projects

    • Boutique Home Centre Shopify homepage with tile promotion and product navigation

      1/4 · A storefront organised around the renovation

      Website development

      Boutique Home Centre

      Boutique Home Centre

      Retail & productsWebsite designShopify

      Melbourne, Australia

      3,592

      published product pages in the Shopify catalogue

      Public sitemap review · 22 September 2026

      Shopify website design for Boutique Home Centre in Melbourne, with a detailed product catalogue, AI-assisted content and a room visualiser.

      Boutique Home Centre’s brief was to move its home-improvement catalogue into a better organised Shopify store and fill gaps in product information.

      • Delivered: Product pages with useful descriptions, specifications and coverage details. Collections with filtering, sorting and product comparison.
      • Outcome: Delivered a store where customers can find a product, compare its details, plan an order and ask about freight before buying.
      Read full website case study

    A closer look

    The work, in three steps.

    Boutique Home Centre

    Boutique Home Centre

    Website project

    Start with the business and its customers.

    Boutique Home Centre’s brief was to move its home-improvement catalogue into a better organised Shopify store and fill gaps in product information.

    • Melbourne, Australia
    • Shopify migration
    • Product content
    Explore the full project
    Boutique Home Centre Shopify homepage with tile promotion and product navigation
    A storefront organised around the renovation
    Inside a launch

    Seven ways a launch
    loses the rankings.

    None of these are exotic. They are what we find on a site that has just been rebuilt, and none announces itself in a browser.

    • Every old URL redirects to the homepage

      A wildcard instead of a map. A redirect to a page that answers nothing is a soft 404.

    • Titles and meta descriptions arrive empty

      They used to come from a plugin. Now they come from code, and a field nobody wired renders blank.

    • The staging index block ships with the site

      A robots file meant to keep the build private, promoted untouched. It de-indexes the live site.

    • The content only exists after JavaScript runs

      The response a crawler reads is an empty shell. The browser assembled the rest a second later.

    • Redirects chain, loop, or answer with the wrong code

      Chains dilute, loops fail, and a 302 asks Google to carry on indexing the old URL.

    • Canonicals and links point at a host you left behind

      The www host, or the staging domain. The sitemap usually still lists the old URLs too.

    • Tracking stops firing on the new templates

      Nobody can tell whether enquiries fell, when they fell, or which part caused it.

    A migration, actual size

    One cutover. No second attempt.

    Less a judgement call than an inventory: every indexable URL either has a destination, or it does not.

    • 1

      attempt at cutover

      The switch happens once. Everything before it is preparation, everything after it is repair.

    • 2

      crawls that decide it

      The old site before it is touched, the new one once it is live. The difference is the job.

    • 301

      the redirect that carries

      A permanent redirect passes the signals on. A 302 asks Google to keep the old URL instead.

    • 404

      what an unmapped URL returns

      Anything missing from the map answers with nothing. Worse is a redirect to an unrelated page.

    • 200

      the status that proves nothing

      A page can answer 200 with an empty title and no inbound link. Green is not a grade.

    • 0

      indexable URLs missing from the map

      The only acceptable number. A wildcard cannot tell a service page from a tag archive.

    The site looks finished. That is what makes a bad migration hard to see.

    A rebuilt site gets inspected on the pages the team helped design. The damage sits on the long tail — older posts, service variants, the pages quietly earning enquiries.

    None of it is visible in a browser, only in a crawl, and only against an earlier one.

    The record

    Australia · UK · KSA · UAE · NZ

    250+

    Active client engagements

    Search, paid media, web and tracking under one roof

    Google reviews

    5.0

    Rating across every review

    We ask our own customers the same way before we sell it to you

    The SoudCoh Standard v1.0

    41

    Clauses published in full

    The operating rules, written down where you can read them first

    Firm-level figures from the SoudCoh record, not a forecast for your launch. Migration work is reported against your own pre-launch crawl.

    Ten things happen on a migration. Here they are, in order.

    Most of it sits before the launch. A migration booked in go-live week is already a recovery job.

    1. Crawl and inventory the site you have

      Every indexable URL with its title, description, canonical, headings, structured data and links, captured before anything changes.

    2. Map old to new, row by row

      A reviewable ledger with a destination for every URL, decided by a person rather than a wildcard.

    3. Carry the titles, descriptions and canonicals across

      Each one transfers unchanged or changes deliberately and is recorded. On a new stack they come from code.

    4. Rebuild the internal links as links

      Navigation, pagination and filtered listings as anchors a crawler can follow, not application state a click reveals.

    5. Check what the crawler actually receives

      The response before JavaScript runs, not the page after. If the copy appears later, the template is fixed.

    6. Block staging properly, and only staging

      Kept out of the index by a method that cannot travel with the build into production.

    7. Plan the launch in tranches

      Sections cut over in stages, so a defect is contained to one tranche and can be rolled back alone.

    8. Cut over, then crawl immediately

      Redirects, robots file, sitemap, canonicals and tracking verified on the live host within the hour.

    9. Diff the two crawls and work the list

      Lost titles, pages with no inbound link, chained redirects, canonicals on the wrong host, URLs no longer indexable.

    10. Re-check the ledger, then hold the window open

      Every redirect tested again live, then indexing, coverage and enquiries watched for weeks. Some defects surface late.

    How an engagement runs

    Keyed to the launch, not to the calendar.

    1. Before the build

      Baseline and inventory

      We crawl the current site while the new one is still a design. Nobody else will keep that record.

    2. During the build

      The map and the templates

      The ledger is written and reviewed, and templates checked for titles, canonicals and crawlable links as built.

    3. Launch week

      Rehearsal on staging

      The whole cutover is run on staging: redirects tested, crawl compared, index block confirmed, rollback agreed in writing.

    4. Launch day

      Cutover and the first crawl

      The tranche goes live and is crawled within the hour, on the live host, before anyone goes home.

    5. Week 1

      The diff, worked down

      The two crawls are compared and defects fixed in the order of what each URL was earning.

    6. Weeks 2–8

      Recovery, and the honest version of it

      Read against your own pre-launch baseline. Some movement is normal; we say which part is settling.

    You keep the baseline crawl, the inventory and the ledger whether or not we run the launch.

    SoudCoh Compound™

    Migration work lives in two of the six stages.

    Compound is how our team works — six stages every change passes through. A launch leans on these two.

    • Sweep

      Waste is found daily, named, and priced.

      On a migration the sweep is the crawl diff: missing titles, chained redirects, orphaned pages, canonicals on the wrong host, found and named.

    • Statement

      A fixed rhythm, good news or bad.

      Reporting runs against your own pre-migration baseline, including the weeks where the honest answer is that it is still settling.

    FAQ

    Migrations, answered.

    Timing, cost, contracts, who owns the map, what a staged launch means, and what happens when rankings do not recover.

    The first call is free and there is no deck.

    Ask us about your rankings

    It follows the build, not a calendar. The inventory and URL map take one to three weeks, and we keep watching the site for about eight weeks past cutover.

    Some movement is normal for a few weeks while the new URLs are re-crawled. A sustained fall is not, and it is almost always a specific defect.

    You can, and many have to. But two changes landing together means you cannot tell which caused a fall. Where the timeline allows, we sequence them.

    Usually. Without a baseline crawl we rebuild the old URL set from archive copies, server logs, the old sitemap and search data, then map what was lost.

    You do. It is a document you keep, not a rule buried in a server config. Your developers implement it, and it stays with you.

    Yes, and that is the normal arrangement. We need the staging URL, permission to crawl it, and one named person who can implement the ledger.

    Sections cut over in tranches instead of the whole site in one night. If something breaks it broke inside one tranche, so rolling back stays small.

    Yes, and it is one of the more common jobs we do. URLs stop coming from permalink rules, titles and descriptions stop coming from a plugin, and content that sat in the HTML may now render client-side. All three are checkable before launch.

    We work the diff until the list is empty, then say whether what is left is a defect or a competitive change. Sometimes the honest answer is to wait.

    It scales with how many indexable URLs there are and how much of the implementation is ours. Quoted after the baseline crawl. The first call is free.

    No long-term lock-in. A migration is scoped around a launch date, and the weeks we spend watching it afterwards are part of the same work.

    Before launch, the inventory and the URL map. At cutover, the live verification. After it, the crawl diff and enquiries read against your own baseline.

    Get the pre-launch crawl

    We crawl the site you have now, inventory every indexable URL with its title and canonical, and hand you the baseline. Yours to keep either way.

    No pitch deck. No upsell. A real conversation and a file your developers can act on.