Squarespace to WordPress: URL Mapping and the 301 Plan

Squarespace is comfortable to leave until you look at the URLs. Blog posts carry dates, collections sit in folders you did not name, tags and categories generate archive pages, and the same page answers at three addresses with different parameters. A WordPress build that ignores those habits launches with hundreds of 404s that no theme can fix.

This is the URL side of a Squarespace migration: how the platform structures addresses, how to find which ones matter, and how to write the 301 plan as a set of rules rather than a thousand hand-typed lines.

How Squarespace builds URLs

Knowing the patterns lets you write rules instead of rows.

Two things follow. First, every collection type needs its own mapping rule. Second, the archives (/category/, /tag/, ?offset=) are where most stray indexed URLs live, because Squarespace links to them from every post.

Step 1. Find out what is actually indexed

Do not map from the Squarespace admin. Map from what Google has.

1. Export the Pages report from Search Console for the property. This lists indexed and not-indexed URLs with a reason.
2. Export the Performance report by page for the last 16 months. Join it to the first list on URL.
3. Crawl the live site with a crawler that follows links, and note any URL that is linked but was not in either export.
4. Pull the Squarespace sitemap at /sitemap.xml. It only lists what Squarespace wants indexed, so it under-reports.

Merge the four into one sheet with columns for clicks, impressions and referring domains. Everything with clicks or external links is a must-map. Everything else is a should-map if it has an obvious destination, and a deliberate 410 if it does not.

Step 2. Decide the WordPress permalink structure

The decision that saves the most redirects is choosing WordPress permalinks that reproduce Squarespace's structure for the URLs that matter.

• Pages: set the slug to match. /about becomes /about/. The trailing-slash change is a single site-wide redirect rule, not a per-page one.
• Dated blog URLs: set WordPress permalinks to /blog/%year%/%monthnum%/%day%/%postname%/ if you want to keep them working natively. Squarespace uses non-padded months and days (/2024/3/4/) while WordPress pads them (/2024/03/04/), so you still need one pattern rule to insert the zeros. If you would rather drop dates, map each dated URL to /blog/%postname%/ with a pattern rule and accept that this is a change Google has to recrawl.
• Products: WooCommerce uses /product/product-name/ by default. Either change the WooCommerce base to /shop/p/ (supported) or map /shop/p/(.*) to /product/$1/.
• Categories and tags: WordPress uses /category/name/ and /tag/name/ at the root, Squarespace nests them under the collection. Map /blog/category/(.*) to /category/$1/ with the value lowercased and %20 replaced by a hyphen.

Step 3. Write the 301 plan as rules plus exceptions

A plan written as rules is testable and short. A plan written as one row per URL is long and drifts out of date before launch. Use both: rules for the patterns, an explicit list for the exceptions.

Pattern rules

# Trailing slash for pages
RedirectMatch 301 ^/([a-z0-9-]+)$ /$1/

# Dated blog posts: pad month and day, keep slug
RewriteRule ^blog/(\d{4})/(\d)/(\d{1,2})/([^/]+)$ /blog/$1/0$2/$3/$4/ [R=301,L]
RewriteRule ^blog/(\d{4})/(\d{2})/(\d)/([^/]+)$ /blog/$1/$2/0$3/$4/ [R=301,L]

# Products
RewriteRule ^shop/p/([^/]+)$ /product/$1/ [R=301,L]

# Archives
RewriteRule ^blog/category/([^/]+)$ /category/$1/ [R=301,L]
RewriteRule ^blog/tag/([^/]+)$ /tag/$1/ [R=301,L]

# Parameters Squarespace should never have exposed
RewriteCond %{QUERY_STRING} (^|&)(format|lightbox|offset)= [NC]
RewriteRule ^(.*)$ /$1? [R=301,L]

The exact syntax depends on your host. The redirect plugin you choose will have a regex mode that takes the same patterns.

The exceptions list

Some URLs will not follow the patterns: pages you renamed on purpose, products that were discontinued, posts you merged. Keep those in a plain two-column list and load them before the pattern rules, so the specific mapping wins.

Rules that keep the plan honest

• Never chain. If a dated post is also being renamed, map the old dated URL straight to the final slug, not to the padded date and then to the new slug.
• Lowercase and de-encode. /blog/category/Web%20Design must land on /category/web-design/. Squarespace's case sensitivity is a trap here; test with the exact string from Search Console.
• Retire with intent. For a discontinued product with no successor, return 410. A 301 to the shop home is a soft 404 and delays the cleanup.
• Do not redirect the sitemap. Squarespace's /sitemap.xml will be replaced by WordPress's own. Just make sure the new one is submitted.

Step 4. Test against the real list, on staging

Load the rules and the exceptions on staging. Take the merged sheet from step 1, substitute the staging host, and crawl the old URLs in list mode. You are looking for three numbers: how many return 301 to a 200, how many return 404, and how many involve more than one hop. Only the first should be non-zero. Fix the patterns until it is.

Then crawl staging from the home page normally. Zero 404s, one canonical per page, and no internal link that points at an old-format URL. Squarespace exports often carry absolute links to the old domain inside post bodies; a find-and-replace on the content table fixes that in one pass.

Step 5. Cutover and the first crawl

Lower the DNS TTL two days ahead. On the day, point the domain, wait for the certificate, remove the staging noindex, and confirm robots.txt is the production one. Re-run the old-URL crawl against the live domain within the hour. Submit the new sitemap. Inspect the top commercial URLs in Search Console and request indexing.

Watching the redirect log

For the first month, read the redirect and 404 logs weekly. Old Squarespace URLs you never saw in the exports will appear: shared links in old newsletters, images hot-linked from forums, an archive page a partner linked to years ago. Each one is a row to add. By week four the log goes quiet and the migration is finished in the only sense that matters: nothing Google or a human ever linked to returns an error.

What we bring to this

We write the rules, not the rows, so the plan is short enough to review and long enough to be complete. We test it against the real indexed list on staging and show you the three numbers before DNS moves. And we keep watching the log after launch, because that is where the last five percent of a migration lives.