Wix to WordPress redirects: /post/ urls, old #! links and the Redirection import

Every Wix app has its own folder, and the folder names are fixed or nearly so. Wix lets you change the post prefix of blog posts to another unused word, which is worth checking before you assume the default (Wix blog post urls).

copy-of pages — Wix names a duplicated page /copy-of-…, and those urls often stay live for years because nobody renames them. On WordPress the page gets a proper slug, so the old one needs a row.

WordPress’s permalink setting is the cheapest redirect there is. Under Settings, Permalinks, a custom structure of /post/%postname%/ gives every post the same path it had on Wix. WordPress always adds the trailing slash, and a request for /post/spring-menu is answered with WordPress’s own redirect to /post/spring-menu/: the canonical redirect adds or removes the slash to match the permalink structure (redirect_canonical). One hop, then the post.

Silentfrog treats /post/spring-menu and /post/spring-menu/ as the same page, so these rows are exact matches and stay out of the export. What shows up instead are the posts whose slug changed on the way: a post imported with a different slug becomes a fuzzy match on its title and lands in the review list.

If you would rather have /blog/slug/, that is fine too; it just means one regex rule more, /post/(.*) to /blog/$1, and the matcher still catches the changed slugs.

The first generation of Wix sites had urls like example.com/#!about/c1x2y. Everything after the # is a fragment, and a browser never sends the fragment to the server. WordPress receives a request for / and nothing else, so no plugin and no .htaccess rule can tell one of these links from another. Google deprecated the crawling scheme behind them in 2015 (Google, deprecating the ajax crawling scheme), and Wix moved its sites to normal paths since, so these links only live on in old backlinks and bookmarks.

Silentfrog drops fragments when it reads a url, exactly like a server, so they never become rows. If your backlink report shows #! links that still matter, the only fix is a few lines of JavaScript on the homepage that read location.hash and forward to the right page. That is a client-side redirect, not a 301, and Google may or may not follow it. For most sites the honest answer is to let those visitors land on the homepage.

Wix’s folder-per-app structure is a good fit for directory rules. In Silentfrog, add a rule for /product-page to /product with keep sub-paths, tick export as wildcard rule, and check the live preview for slugs the new shop does not have; those land in needs review instead of being exported blind (directory rules). The same works for /single-post, /blog/categories and /blog/tags.

In the Redirection export each such rule becomes one regex row, ^/product-page/(.*)$ to /product/$1, written after the exact rows so a specific redirect inside the folder is matched first.

WordPress has no redirect importer in core. The Redirection plugin imports a csv under Tools, Redirection, Import/Export: source, target, then optionally a regex flag (0 or 1) and the status code, comma-separated, no header (Redirection import and export). Pick wordpress · redirection plugin in Silentfrog’s export and the file is in exactly that shape. Yoast SEO Premium and Rank Math PRO have their own formats in the same picker (importing redirects into WordPress).

/copy-of-pricing,/pricing,0,301
/blog,/journal,0,301
^/product-page/(.*)$,/product/$1,1,301
^/single-post/(.*)$,/post/$1,1,301

the trailing slash on targets — Silentfrog writes paths without a trailing slash, so a target reads /pricing, and WordPress then adds its own redirect to /pricing/. That is two hops for one old url. To avoid it, add the slash to the target column before the import, for example in a spreadsheet, leaving file urls such as .pdf alone. The regex rows need it too: /product/$1/, /post/$1/.

ignore trailing slashes — Redirection can match /your-url and /your-url/ as one source when the option is set, per redirect or as a default; with regex rules you handle the slash in the expression yourself (Redirection url matching). Wix urls have no trailing slash, so this matters mostly for links people typed by hand.

Wix publishes a sitemap index at /sitemap.xml with one sub-sitemap per app: pages, blog posts, categories, products. Silentfrog follows the index on its own. Add the Search Console pages export to the url list for posts and pages the sitemap no longer lists, and the redirects already in Wix’s url redirect manager, so they are resolved against the new site directly instead of chaining (finding the urls nothing links to).

If the Wix site was switched off before anyone built the list, the old pages can come from a saved sitemap or a url list instead of a crawl (when the old site is gone). Matching then runs on the url alone, so expect more rows to review.

• Set the WordPress permalinks to /post/%postname%/ (or decide on /blog/ and plan one rule more) before the content import.
• Export the Search Console pages report and the Wix redirect list while the Wix site is live.
• Start a run with the Wix domain as the old site and the WordPress staging domain as the new one; paste the extra urls into the url list (starting a run).
• Add one directory rule per Wix folder that moves as a whole, exported as a wildcard.
• Review what is left in needs review, mostly renamed pages and posts whose slug changed, and verify what you accept.
• Download the redirection file, add trailing slashes to the targets, import it, and move the domain.
• Crawl the old url list against the live site: one 301, then 200.

Most Wix sites are small enough that the first 50 pages, which are free, show you the whole map or most of it. No signup, and only the old site’s pages count.

• Set WordPress's permalinks to /post/%postname%/ and imported Wix posts keep their urls; only changed slugs need a row.
• Wix's app folders (/product-page/, /single-post/, /blog/categories/) are one regex rule each in the Redirection plugin.
• #! links never reach the server; no WordPress redirect can catch them.
• Add trailing slashes to the targets before the import, or every redirect takes a second hop.
• Resolve the redirects Wix already had against the new site, not against their old targets.