A PrestaShop migration — a new version, new hosting or a new theme — often affects page addresses, page structure and site speed: three things Google watches closely. Poorly prepared, it can make traffic drop for weeks, sometimes months. Well prepared, Google barely notices it. Here is the method, step by step.
What can break during a migration
- Page addresses: a version change or new settings can alter the URL format of products and categories (with or without an ID, with or without the category in the address).
- SEO tags: titles, meta descriptions, canonical tags and language versions, lost or reset by a new theme or an incomplete import.
- Product structured data (price, availability, reviews), which powers rich results in Google.
- Speed: new hosting or a heavier theme can slow down loading.
- Indexing itself, if a setting from the test copy ends up in production (see below).
Before migrating: take inventory
Before touching anything, you need to know what exists:
- the list of pages that get traffic, exported from Search Console (Performance report, Pages tab);
- the full list of URLs, from the XML sitemap or a crawler such as Screaming Frog;
- the title and meta description of the most important pages;
- the redirects already in place;
- a full, verified backup of the database and files (see the backup rule almost nobody follows).
This inventory is the reference used afterwards to check that nothing has disappeared.
Migrate on a test copy that Google cannot see
The migration should never be done directly on the live store. A test copy lets you check the catalog, the checkout, payment modules, emails and performance, with no risk to ongoing sales.
This copy must not be indexed: protect it with a password (the safest option) or block indexing. Otherwise, Google may discover a duplicate of your store.
Keep the addresses, or redirect every one of them
The simplest option is to keep exactly the same URL format: in Shop Parameters > Traffic & SEO, use the same address patterns as on the old store. No redirect is then needed.
If addresses change, every old URL must redirect to its new equivalent with a 301 redirect. Build a mapping table (old address, new address) from the inventory, then turn it into rules, for example in the .htaccess file:
Redirect 301 /12-wooden-chairs.html https://www.store.com/living-room/12-wooden-chairs.html
Redirect 301 /3-living-room https://www.store.com/3-living-room-furnitureTwo mistakes to avoid: redirecting every old page to the home page (each page’s ranking value is lost), and creating redirect chains (A to B, then B to C), which slow things down and dilute that value.
Switch-over day
- Pick a quiet time, and warn customers if the store has to close for a few minutes.
- Check the
robots.txtfile: a test copy that blocks all robots (Disallow: /) copied as-is to production is the mistake that makes a store vanish from Google within days. - Remove the test copy’s password protection or indexing block if they were carried over to production.
- Submit the new XML sitemap in Search Console.
Right after: check a sample of pages
On about twenty representative pages (home, categories, products, CMS pages), check:
- that the address is unchanged, or redirects in a single step to the right page;
- that the title and meta description are the same or better;
- that the canonical tag points to the right address, and that language versions are correct on a multilingual store;
- that product structured data is present (with Google’s Rich Results Test);
- that loading time has not increased.
A full crawl of the new store then finds 404 errors and redirect chains.
The following weeks: monitor
Even a well-prepared migration needs follow-up. In Search Console, watch for non-indexed pages, 404 errors and the positions of important keywords. A slight fluctuation in the first days is normal; a lasting drop signals a problem to fix. Keep redirects in place for at least a year, and ideally forever if they do no harm.
The checklist
- Inventory: pages with traffic, URL list, titles, existing redirects.
- Full, verified backup.
- Migration on a protected test copy, never in production.
- Same URL format, or a mapping table and page-by-page 301 redirects.
- Switch-over day:
robots.txtchecked, indexing block removed, sitemap submitted. - Sample of pages checked: address, title, canonical, structured data, speed.
- Several weeks of monitoring in Search Console, redirects kept.
Going further: my expertise: Freelance PrestaShop developer · read also: PrestaShop: the mistakes that slow down your online store
