October 24, 2026

Wix to WordPress redirects: mapping every Wix URL

Moving from Wix to WordPress changes most of your URLs, because Wix puts blog posts under /post/ and store products under /product-page/, and WordPress uses neither. Each old URL that earns traffic or links needs a 301 redirect on the WordPress side, added with a redirect plugin, in .htaccess on an Apache server, or in your host's redirect tool.

This guide covers the Wix side of the move: how to collect the old URLs, what shapes they come in, where each type should land in WordPress, and what to do about the old #! links that no server redirect can see.

Get the full list of old URLs before you switch

Collect the list while the Wix site is still live. Once the domain points at WordPress, the old site can't tell you what it had.

  • The sitemap. Every Wix site has a sitemap index at /sitemap.xml that lists one sitemap per content type: /pages-sitemap.xml, /blog-posts-sitemap.xml, /blog-categories-sitemap.xml, /store-products-sitemap.xml, /dynamic-{prefix}-sitemap.xml for CMS pages, and others for events, bookings and portfolio projects. Work through one type at a time. Wix's list doesn't include blog tag pages or store category pages, and the same article warns that a page whose canonical tag you changed may disappear from the sitemap, so check Search Console for those.
  • Existing redirects. Wix serves any redirects you set up in its URL Redirect Manager. Export them from SEO & GEO > Tools and settings > URL Redirect Manager, then More Actions > Export redirects. They cover URLs the site used before, which other sites may still link to, and they stop working when the domain leaves Wix.
  • Search Console. Google's site-move guide says to build the list from sitemaps, server logs or analytics, and the Links report. Map the pages that earn clicks and links first.

How Wix builds its URLs

Type Wix default Source
Page /about URL structure in SEO settings
Blog feed /blog About blog web addresses
Blog post /post/{post-slug} About blog web addresses
Blog category /blog/categories/{category} Blog categories
Blog tag /blog/tags/{tag} Blog tags
Store product /product-page/{product-slug} URL structure in SEO settings
Store category /category/{category} New category page experience
CMS item (dynamic page) /{collection-name}/{primary-field} Dynamic page URLs
Other languages /fr/…, fr.example.com/… or /?lang=fr Multilingual URL structure

Treat these as defaults, not facts about your site:

  • Prefixes can be renamed. Wix lets you rename the blog and post prefixes (but not remove post), and change the product URL structure in SEO settings. When the structure changes, Wix redirects the old URLs automatically by default. A site that renamed a prefix can have links pointing at both forms, so look for both in Search Console.
  • Store categories. The /category/ path belongs to Wix Stores' newer category page. On the older setup there was no category page: products appeared on shop pages or regular pages with a product gallery, so those sit at whatever page slug you gave them, such as /shop or /mugs.
  • CMS items. Dynamic page URLs are built from field values, which Wix lowercases, with spaces turned into dashes. The structure can include more than one field, so read the CMS sitemap rather than guessing the pattern.
  • Tag URLs can't be edited, so their slugs come straight from the tag names.

Where each type lands in WordPress

WordPress sets post URLs under Settings > Permalinks. A fresh install uses Plain permalinks, /?p=123, so choose a structure before you build the map. Post name gives /glaze-guide/, the closest match to a Wix post slug.

On the same screen, the Category base and Tag base set the prefixes for archive pages. They default to category and tag, and you can change them but not remove them. A Wix category at /blog/categories/glazes therefore lands at /category/glazes/ unless you pick another base.

If the store moves to WooCommerce, products land at /product/{slug}, product categories at /product-category/{slug} and product tags at /product-tag/{slug}. WooCommerce lets you change all three under Settings > Permalinks, and says the product base must differ from the category and tag bases. For the full list of URL types a WordPress and WooCommerce site produces, see the table in WordPress to Shopify redirects, read from the other direction.

Wix URL to WordPress URL

Wix URL Example WordPress destination Redirect?
Page /about /about/ None if WordPress serves the page at the same path
Blog feed /blog your posts page 1:1
Blog post /post/glaze-guide /glaze-guide/ Pattern rule if slugs match
Blog category /blog/categories/glazes /category/glazes/ Pattern rule if slugs match
Blog tag /blog/tags/stoneware /tag/stoneware/ 1:1, or 404 for thin tags
Store product /product-page/blue-mug /product/blue-mug/ Pattern rule if slugs match
Store category (new) /category/mugs /product-category/mugs/ 1:1 only (see below)
Shop page (old) /shop a product category or the shop page 1:1
CMS item /team/sara wherever you rebuilt it 1:1
Other language /fr/about depends on your multilingual plugin 1:1
Old #! link /#!about/c1x2y the page it named Not possible on the server (see below)

The example paths are illustrations of each shape. Copy the "redirect to" value from the WordPress site itself, in the exact form WordPress shows it, trailing slash included, so each redirect takes one hop.

Notes on the rows:

  • Pattern rules need matching slugs. A rule that turns /post/(anything) into /(anything)/ is only right if every post kept its Wix slug. Check before you trust it: strip /post/ from each URL in the Wix blog sitemap and look for the result in WordPress's own sitemap, which core publishes at /wp-sitemap.xml since version 5.5 (an SEO plugin may replace it with its own). Every post that doesn't match needs its own row, placed above the pattern rule.
  • Store categories collide with blog categories. Wix's store category path /category/mugs is the same shape as WordPress's default blog category archive /category/{slug}/. A pattern rule on /category/ would send your new blog category pages to the shop. Give each store category its own exact row, and make sure no blog category uses the same slug, or change WordPress's category base.
  • Pages. If a Wix page and its WordPress replacement sit at the same path, you need no redirect. Load each one on WordPress to confirm the path before you leave it out of the map.
  • Languages. The destination format for translated pages comes from whichever multilingual plugin or setup you choose on WordPress, so map those rows after it's in place. A Wix site on language subdomains needs those subdomains pointed at the new site too, or their redirects have nowhere to run.

Old #! links from before 2016

Wix sites once used URLs like tzufit.wix.com/change-my-url#!my-page-title/wzupj. Wix's engineering team describes dropping that format for ordinary paths, a move finished by the end of August 2016. Links in the old shape can still sit on forums, directories and old emails, but you only need to act if you find some that still matter.

A server redirect can't match them. Everything after # is the fragment, which RFC 3986 says is dereferenced solely by the user agent: the browser keeps it and asks the server for the part before it. Wix's engineers give the same reason for leaving the format: hash fragments aren't sent to the server. A request for example.com/#!about/c1x2y reaches WordPress as a request for the home page, and neither .htaccess nor a plugin sees the rest. Wix handled these links with JavaScript in the browser, per the same engineering post, and that script leaves with the Wix site.

What still works is a small script on the WordPress home page that reads the fragment and sends known values on:

<script>
  var oldLinks = {
    "#!about/c1x2y": "/about/",
    "#!contact/c3z4w": "/contact/"
  };
  if (oldLinks[location.hash]) location.replace(oldLinks[location.hash]);
</script>

Copy each key exactly from the old links you found. This helps people who click those links. It does little for search: Google deprecated the AJAX crawling scheme in 2015 and says you can't rely on URL fragments to work with Googlebot, and it treats JavaScript redirects as a last resort.

Adding the redirects in WordPress

Use a permanent redirect. Google treats a 301 or 308 as a signal that the target should be canonical, and a 302 or 307 as a temporary move that leaves the old URL in place.

With a plugin

The Redirection plugin handles redirects inside WordPress, so it works without access to the server configuration. It imports and exports CSV, supports regular expressions, and logs 404s, which helps after launch. To write a pattern rule, tick the regex option on the redirect, capture the part to keep in brackets, and refer to it as $1. Here ([^/]+) captures the slug and /?$ lets the rule match with or without a trailing slash:

Source URL Target URL
^/post/([^/]+)/?$ /$1/
^/product-page/([^/]+)/?$ /product/$1/
^/blog/categories/([^/]+)/?$ /category/$1/

Start each source with ^. Redirection's docs say it makes the pattern match only at the start of the URL, and an unanchored pattern can match inside its own target and loop.

In .htaccess on Apache

If your host runs Apache and lets you edit .htaccess, Apache's RedirectMatch does the same job:

RedirectMatch 301 ^/post/([^/]+)/?$ /$1/
RedirectMatch 301 ^/product-page/([^/]+)/?$ /product/$1/
RedirectMatch 301 ^/blog/categories/([^/]+)/?$ /category/$1/

Details that break these:

On a host that doesn't run Apache, use the host's redirect tool or the plugin, and check that the tool sends a 301.

Rewrite the redirects Wix already had

Go through the file you exported from Wix's URL Redirect Manager. For each row, find the Wix URL it pointed to, look up that URL's WordPress destination in your map, and add a row from the old path straight to the WordPress URL. A row that points at the Wix URL instead creates a chain. Google's site-move guide says to redirect to the final destination and avoid chains.

What to leave as a 404

Google's site-move guide says content you aren't moving should return a 404 or 410, and warns that sending many old URLs to the new home page can be treated as a soft 404. A reasonable split for a Wix site:

  • Redirect 1:1: every page, post and product you're keeping, plus anything in your Search Console export with clicks or links.
  • Redirect to the nearest parent: categories and discontinued products that earned links.
  • Leave to 404: tags nobody visits, member and checkout pages, and pages you deliberately dropped.

Cutover and after

The redirects have to be live on WordPress before the domain moves, because Wix stops serving its own redirects when the domain points away from it. Build the site and add the redirects on a staging address, test a few, then switch DNS. Google's guide also says to build and test the new site before the move. Then:

  • Load a sample of old URLs in a private window: one of each row type in the table, plus your top pages from Search Console. Each should land on the right page in one hop.
  • Update internal links and the sitemap. Content imported from Wix can still hold links to /post/ URLs. Google's guide says to update internal links and submit the new sitemap.
  • Watch for errors. The same guide says to monitor Search Console's sitemap and indexing reports, server logs and analytics. Redirection's 404 log shows old URLs your map missed.
  • Keep the redirects. Google recommends keeping them for as long as possible, ideally at least a year.

If the domain stays the same, Google's Change of Address tool doesn't apply; it is only for moves between domains or subdomains.

If you'd rather not build the spreadsheet by hand, RedirX (walkthrough) starts from your old and new URL inventories, proposes a WordPress destination for each Wix URL, keeps every proposal in review until it is confirmed, and exports the approved redirects.