Case Study: Migrating a 1,576-Product Porsche Parts Store from iGetWeb to 100% WordPress — Like-for-Like Move, Redesign and 301s for Every Link

Who this case is for

If your shop has hundreds or thousands of products on iGetWeb or another hosted site builder and it’s time to move, whether because the platform is closing or because you want a site that works on phones and that you can edit yourself, the first question is almost always the same: “Will I lose my Google rankings?”

This case is the long answer to that question. We walk through every step we actually took with a Porsche genuine parts store carrying 1,576 products: demos the client could click through, a like-for-like move of the whole shop, the switch to WordPress, the redesign, 301s for every link, and the handover to the shop’s own team.

MCR Autoparts has given us permission to name them and show the work in this case study.

Watch the project summary (2:30)

From our YouTube channel (Thai narration): old site and brief → website migration → SEO migration → before/after → new homepage → mega menu → product page → mobile

Before / after: the old site and the new one

BEFORE · old site

AFTER · new site

BEFORE · mobile

AFTER · mobile

Screenshots of the old site (before the move) and the new site on the test domain, 6 Oct 2026 · a personal email address is blurred

1. The shop, and why it had to move

MCR Autoparts imports genuine parts for Porsche, supercars and European cars, and has been doing it for more than 10 years. The way it sells is interesting: there are no prices on the website at all. Every item is “Call For Price”. Customers send their VIN over LINE, the shop confirms the part fits, and then quotes. So the website is a catalogue: its job is to help people find the part, then get them into LINE.

The first message we received from the shop said they needed to move their catalogue website from the existing hosted platform (iGetWeb) to WordPress or another suitable system, because the provider will be closing at the end of the year.

So this move had a deadline, and what had to come along wasn’t just the look of the site. It was 1,576 products, all their photos, and every link built up since 2015.

The shop asked for something we really like: two demos before deciding, one hand-coded and one on WordPress, using the same 20–30 real products. They wanted to see how adding a product, changing a photo or changing a category works, whether there are fields for part numbers, car models and SEO, what the sitemap and 301s look like, and how it all behaves on a phone.

An owner who asks that isn’t just after a prettier website. They want to know they can run it themselves afterwards, and that nothing will get lost on the way.

2. Phase 0: two demos the client could click through

On 11 September 2026 we put both demos on test sites, using 30 real products in 9 categories and the real photos from the old site throughout. We rebuilt the old homepage layout piece by piece, from the search bar and 5-button menu to the banner and three-column layout, so the shop saw its own products on the new system rather than a sample template.

We built both demos before charging anything. In our experience, ten minutes of explaining is worth less than letting an owner add one product themselves. Once they’ve tried it, the conversation about systems gets a lot shorter.

3. Before touching anything, we audited the old site

Before any migration we want to know two things: what has to come across complete, and what’s most valuable and must not break. So we went through the live pages, pulled data from Ahrefs, and later compared everything with the shop’s official product export.

Ahrefs data from 18 Sep 2026 (estimates) · other findings from the live site and the shop’s export

These numbers told us two things. First, Google had almost no way to walk into over a thousand products, which is a big opportunity for the new site to win back. Second, what needed the most care during the move was the homepage, with links from 609 domains pointing at it, plus the 4 pages still getting Google visitors: the Cayenne 958, Boxster 986 and Carrera 991 categories, and a Tesla Model 3 wheel product.

4. Phase 1: a like-for-like move first, improvements later

Many owners want to change platform and design at the same time. We advise against it: if something goes wrong on launch day, you can’t tell whether the move or the new design caused it. So we move everything across, complete and looking the same, first. Once it’s stable and we’ve proved nothing is missing, we redesign on a base we trust. Regular customers don’t get lost in the meantime, either.

4.1 Collecting the whole shop when the sitemap had no products

Normally we’d start from the sitemap, but this one had no product pages. So we walked the category tree instead (make → model → part sub-category), collecting product IDs make by make until every one was found, then fetched every product page.

While sorting categories we found some in the wrong place, such as models sitting at the same level as makes (“Porsche 991.2”, “R8 2024 model”), so they went back where they belong. “Rolls Royce” and “Rolls-Royce”, which had been living separately, became one category.

Before moving on, we counted to make sure nothing had slipped through:

4.2 Matching the original design, measured rather than eyeballed

“Make it look the same” always drifts if you do it by eye alone, so we measured the real thing. We took 1,440 px screenshots of the old and new sites and compared them side by side for 8 page types (home, make, model, all products, product, payment, contact, about), measured the position and size of elements on the old site in the browser, and kept the original CSS for reference. Theme images such as buttons, bars and icons are the original files, byte-for-byte identical.

In a few places the shop chose “the same, but keep the better version”: OEM / make / model rows on product pages that link to their categories, and LINE/phone buttons in place of ORDER NOW. The cart and language flags, which weren’t really in use, were dropped.

5. Phase 2: moving to 100% WordPress

Once the shop had seen its whole catalogue on the test site, on 22 September we settled on 100% WordPress for three simple reasons. A parts shop adds products almost every week, so its own team has to be able to do it. Saving has to publish immediately, with no build step to wait for. And since the shop doesn’t sell through a cart, there’s no need to carry all of WooCommerce.

During the switch we screenshotted 14 pages before and after and compared them pixel by pixel. Inner pages differed by only 0.01–0.14% on desktop. The whole back end changed and visitors would barely notice, which was exactly the point.

Cleaning the data along the way

If you’re moving house anyway, you might as well tidy up:

• Repeated keywords in 53 descriptions were removed without touching product information
• 22 product names that were too vague or duplicated gained a clear make and model
• About 10 products had their variant detail (“facelift”, “(rear)”, “991.2”) only in the old sub-category name; we moved it onto the product, or it would have vanished with the old category
• The About/Contact images became real text
• Every product got a temporary part number the team can overwrite with the real one later

6. Phase 3: seven redesign rounds, shaped by the shop

With everything moved and the system stable, it was time to make it look good. On 6 October 2026 the shop sent the header design they wanted, and we worked through seven rounds that day, saving a copy of each one so any earlier version can be brought back straight away.

You’ll notice the “send your VIN to check parts” button sits on the first screen, with LINE/phone in the header of every page and a sticky bar on mobile. That’s because this shop takes orders over LINE; every sale starts with that button. However good the design looks, it’s useless if customers can’t find it.

7. SEO migration: 301s for every old link pattern

This is the real heart of any website move. A site that has been around for years holds value you can’t see: old links that Google remembers and that other sites point to. If those links turn into 404s after the move, everything they carried goes with them.

7.1 Listing old links from four sources

No single source is complete, so we pulled from four:

1. The full catalogue crawl of the live site (section 4.1)
2. The old sitemap
3. Pages known to Ahrefs, pages with traffic and pages with backlinks; an “add to cart” link that every other method missed turned up here
4. The shop’s official export and an offline copy of the site

7.2 Where each kind of old link goes

7.3 Two choices that keep these 301s from breaking

First, we match on the numeric ID only. Old links on this site carry the Thai product name in the URL, and when links get shared around they’re often truncated or encoded differently. Match on the name and those links break. The product ID never changes, so however mangled the name gets, the link still lands on the right page.

Second, we didn’t stuff 3,274 lines into an .htaccess file, which the server would have to read on every single page view. The old IDs are stored with products and categories in the database, and a cached lookup table is built from them. A bonus: if the shop changes a product URL later, its 301 follows automatically, with nobody having to fix anything.

7.4 The same checklist after every change

Every time anything on the site changed, we went through the same checklist again: open all 1,801 URLs in the new sitemap and confirm each returns 200, then try a sample of old links and confirm each 301s to its destination in one hop. It passed every time.

A few edge cases turned up along the way, and each was dealt with:

• An “add to cart” link known to Ahrefs returned 404; it now goes to the product
• 29 categories already empty on the old site now go to their parent instead of the all-products page
• Old tag pages that returned 404 now go to search for the same term
• 3 links that were already broken in the old sitemap got 301s too
• The price filter’s parameter clashed with a reserved WordPress name, so it was renamed

One more small but important thing: we carried the existing Google Search Console verification code over to the new site. On switch day, GSC ownership won’t drop, and the data stays continuous in the same place.

8. SEO analysis and setup across the site

8.1 Template-based Title / Meta / Alt

Nobody can hand-write titles for over a thousand products, and hand-written ones are never consistent anyway. So we designed a template for each page type and let the system fill it from each product’s real data.

The site is Thai-only, so the templates are in Thai (“อะไหล่แท้” means “genuine parts”).

Values for all 1,576 products, every category and every page went into Rank Math, so the shop’s team can keep adjusting them in the admin.

8.2 Schema for a parts store

The popularity stars on product cards are deliberately just a label, not review schema. They aren’t real customer reviews, and marking them up would only invite a penalty from Google.

8.3 Internal links, indexing and speed

Internal links: a make → model mega menu with about 160 links on every page, the same as the old menu but much easier to read, plus make › model breadcrumbs, model chips with product counts on make pages, make/model rows on product pages that link to their categories, and 6 related products per page.

Indexing: during testing every page is noindex and robots.txt is closed, so Google doesn’t mix the test site up with the real one. On launch day a single “Launch” switch turns on indexing, robots and canonicals together. Search results and empty pages are always noindex.

Speed: the homepage HTML used to weigh 436 KB because the homepage schema listed all 1,576 products. Removing that brought it down to 132 KB. We also added a 400 px card image size so phones don’t download oversized images, and improved text contrast and tap-target size on mobile.

8.4 Two rounds of duplicate checks, with the owner deciding

Shops that have been adding products for years usually have some duplicates hiding in there, so we went looking:

12 duplicate groups could only be found from the photos, because the names differed and the shots were taken from different angles. We also found 43 groups where one photo was used for several car models, plus some data errors, such as a product named as a window motor whose photo shows a wiper motor.

We didn’t delete or merge a single product ourselves. The person who knows how two parts differ is the shop owner, not us. Every group went to the shop with links to the old and new pages and tick boxes.

8.5 The shop’s migration report (17 pages)

On 18 September 2026 the shop received a report summarising all of the above in business language, something they could read and decide on without translating any jargon:

1. Migration overview
2. The new site’s URL structure
3. Protecting existing rankings (301 redirects)
4. Technical quality of the new site
5. Product pages that may be the same product
6. Information needed from the shop before launch
7. Southern Whale’s recommendations

9. Quality checks before handover

Lighthouse was measured on the test site after the move to the block theme, before the redesign rounds.

10. Handover: the shop’s team runs it themselves

A good website shouldn’t need a call to us every time new stock arrives.

• The shop’s account can add, edit and delete products, categories, menus, banners, contact details and Title/Description, but can’t reach plugins or data export, so one wrong click can’t break the site
• Saving publishes immediately. We tried it with the shop’s real account: a new product appeared at once on the product page, category, archive, homepage and search, and deleting it correctly produced a 404
• A 24-page Thai manual, readable inside the WordPress admin
• A 2:18 how-to video on adding a product, recorded from the real screen

11. Before / after summary

12. Launch-day checklist

As of 6 October 2026 the new site is ready and the switch to the live domain is being prepared. This is the checklist agreed with the shop:

What you get working with Southern Whale

This case reflects how we work with every shop:

5 lessons for shops planning a website move

Checklist before moving a shop website

• You have a full list of old URLs for every product and category (not just from the sitemap)
• You know which pages get Google traffic and which have links from other sites
• You have a page-to-page 301 plan, not “send everything to the homepage”
• You’ve exported the product data from the old system to compare after the move
• The Google Search Console verification code moves to the new site
• The shop’s team has tried adding a product with their own account before launch
• You don’t cancel the old service until the domain has moved and everything is stable

Questions shop owners often ask

My site is on iGetWeb and has to move. Where do I start? Start by collecting everything before the old system closes: request a product export from the admin, list every old URL (products, categories, tags, menu pages) and note which pages get Google traffic. Then choose the new system, move the products, set page-to-page 301s and carry the Search Console verification over. Don’t cancel the old service until the domain has moved.

Can I clone my iGetWeb site to WordPress so it looks exactly the same? Yes, and it’s the approach we recommend: move like-for-like first, including the menus, make order, product pages and theme images, make sure every product and link is there, then redesign later at the shop’s own pace. If you change the platform and the design at the same time, when something goes wrong you can’t tell which one caused it.

Will moving my website cost me my Google rankings? The main risk comes from old links that turn into 404s or all get sent to the homepage. If every page has its own 301 and you submit the new sitemap, Google can transfer the signals to the new pages. Rankings may move up and down a little at first, so watch Search Console for at least 3 months.

My shop has thousands of products. Do they have to be re-entered one by one? No. In this case we moved 1,576 products with all their photos, badges and tags, then checked them against the official export until every item matched.

Should I choose a hand-coded site or WordPress? If you add products often and want your team to edit and publish instantly, a custom WordPress block theme is the better fit. If the content barely changes and top speed is the priority, a hand-coded site is good too. The best approach is to ask for both demos with your real products and try them yourself.

My shop doesn’t sell through a cart. Do I need WooCommerce? Not necessarily. A shop that sells by enquiry or VIN check can use a lighter product system without a cart, which makes the site faster and the admin simpler.

Moving off iGetWeb or another site builder, but worried about losing what you have?

Send us your site first. We’ll analyse it for free, tell you which links matter and how to move them, and point out what your current site isn’t using yet. If you talk to us and decide not to hire us, that’s fine.

See our WordPress development, web development and SEO audit services, or browse more case studies.