Skip to content
50% OFF $299 $599
Lock in
§ 2.11.2 ARTICLE
Published VerifiedEvery 6 weeks Sources5 named Authored bySquareRank Team

Migrations · § 2.11.2 · How-to

WordPress to Squarespace SEO migration — the Yoast schema rebuild and the redirect map

Squarespace's WordPress importer1 accepts a WordPress XML export and ports posts, pages, and comments into a new Squarespace site. It does not port plugins, custom themes, Yoast or SEOPress structured data, custom post types, custom fields, ACF data, or most advanced WordPress features. The single largest SEO consequence is the Yoast/SEOPress schema graph — every Article, Organization, BreadcrumbList, and Person block Yoast was auto-emitting on the WordPress side is gone on Squarespace and has to be rebuilt via Code Injection3. The plugin-loss list is the second-largest consequence: forms, security, cache, image-optimisation, and analytics plugins are replaced with Squarespace native features or third-party embeds.

This leaf is the WordPress-to-Squarespace playbook. It covers the importer's scope, the Yoast schema rebuild via Code Injection, the plugin loss list, the URL redirect map for WordPress's permalink patterns, and the post-cutover monitoring window. The migrations hub covers the cross-platform context; the JSON-LD leaf ships the schema blocks the rebuild requires.

What Squarespace's WordPress importer ports

The importer reads WordPress's WXR XML export — the file WordPress's own Tools > Export feature produces — and creates Squarespace pages, blog posts, and comments from the contents. It maps WordPress posts to Squarespace blog items, WordPress pages to Squarespace pages, and WordPress comments to Squarespace's commenting layer where the platform supports it. Featured images transfer; gallery images transfer; embedded video links transfer (re-rendered with Squarespace's video block). Anything that lived outside the post/page content body — plugin output, theme files, custom fields, shortcodes that depended on a now-missing plugin — does not transfer.

Squarespace's import documentation1 is direct on the scope: posts, pages, and comments transfer. The documentation explicitly notes that "WordPress plugins and their content (forms, sliders, custom post types, etc.) won't import." WordPress's own export feature2 describes the WXR format as containing only post and page content; plugin databases live outside the XML scope.

The honest WordPress migration cost

Posts, pages, comments

what Squarespace's WordPress importer ports automatically.

Squarespace Help · 2026
0

Yoast structured-data blocks that survive the migration. Every block re-authored via Code Injection.

Yoast SEO Docs · 2026
30-50%

typical organic traffic drop in first 90 days. WordPress sites cluster at higher end of range.

Moz migration guide · 2025

The Yoast / SEOPress structured-data problem

WordPress sites running Yoast SEO or SEOPress automatically emit a comprehensive structured-data graph on every page: Article schema on every blog post (with author, publisher, datePublished, dateModified, image), Organization schema on every page, BreadcrumbList schema on every page, Person schema for author profiles, and FAQPage schema where the operator marked Q&A blocks. Squarespace does not have this automatic emission. After migration, every one of those schema blocks is missing from the Squarespace site, and the operator has to rebuild them via Code Injection. The work is mechanical but it is per-post.

Yoast's structured-data documentation3 describes the graph: "Yoast SEO outputs a comprehensive piece of structured data for the page that includes Article, Organization, BreadcrumbList, and Person." None of that graph is in the WordPress WXR export, because the schema is generated by the plugin at render time. The schema is therefore not preserved; the Squarespace site starts with the partial Article schema Squarespace emits by default and nothing else.

WordPress plugins that do not survive — the replacement map

Plugin functionality has to be replaced with Squarespace native features, third-party embeds, or removed entirely. The common replacement map: Yoast/SEOPress → Code Injection JSON-LD plus the Squarespace SEO panel; Contact Form 7/Gravity Forms → Squarespace Form Block; WooCommerce → Squarespace Commerce (Commerce Basic+ required); Elementor/Divi page builders → Squarespace's section-based editor (rebuild every Elementor template page); WP Rocket cache → not applicable, Squarespace handles caching; Smush/ShortPixel image optimisation → Squarespace's built-in image optimisation toggle; MonsterInsights GA4 → GA4 via Code Injection; Wordfence security → not applicable, Squarespace handles platform security.

The functional replacement is usually straightforward; the ranking-affecting replacement is the schema rebuild. WooCommerce specifically requires careful attention because product URLs change pattern (WordPress's /product/product-slug/ to Squarespace's /shop/product-slug/), product schema is regenerated from scratch on the Commerce side, and any WooCommerce-emitted structured data (Review aggregate ratings, Offer pricing) has to be re-authored.

The WordPress-to-Squarespace 301 redirect map (sample)

WordPress's default permalink structure varies. The most common patterns: /year/month/day/post-slug/, /year/month/post-slug/, /category/category-slug/post-slug/, /post-slug/ (the post-name-only permalink), and /?p=123 (the default ugly permalink, rare on production sites but common on never-touched-after-install sites). Each pattern requires a different redirect approach. The clean rebuild lands the Squarespace pattern as /blog/post-slug/. The wildcard pattern in URL Mappings compresses the bulk where slugs are preserved.

URL Mappings WordPress-to-Squarespace redirect map — common permalink patterns 
 # /year/month/day/post-slug/ pattern (WordPress's default day+name) # Wildcard: source slug becomes Squarespace slug /[year]/[month]/[day]/[slug]/ -> /blog/[slug]/ 301 # /year/month/post-slug/ pattern /[year]/[month]/[slug]/ -> /blog/[slug]/ 301 # /category/cat-slug/post-slug/ pattern /category/[cat]/[slug]/ -> /blog/[slug]/ 301 # Category archive pages — point at the blog index or topic landing page /category/marketing/ -> /blog/?category=marketing 301 /category/seo/ -> /blog/?category=seo 301 # Tag pages — usually point at the blog index (low SEO value) /tag/[anything] -> /blog/ 301 # Author archive pages — point at the founder or about page /author/[anything] -> /about/ 301 # /wp-content/uploads/ media URLs — preserve via a static-asset redirect /wp-content/uploads/[anything] -> / 301 # WooCommerce product URLs (if migrating WooCommerce to Squarespace Commerce) /product/[slug]/ -> /shop/[slug]/ 301 /product-category/[anything] -> /shop/ 301

The wildcard pattern [slug] in Squarespace's URL Mappings captures the variable portion and substitutes it into the destination URL. The pattern is documented in the URL Mappings syntax leaf. For sites with thousands of posts, the wildcard collapses what would be a thousand-row CSV into a handful of lines.

Rebuilding Yoast schema via Code Injection

The rebuild is per-post for Article schema and once-per-site for Organization and Person. On each blog post, paste the Article JSON-LD block into Page Settings > Advanced > Page Header Code Injection. Update the headline, author URL, datePublished, dateModified, and image fields to match the post. The full block lives in the JSON-LD leaf in the Code Injection cluster. For sites with hundreds of posts, the rebuild is a multi-day project — but the schema layer is what makes the migration recover ranking equity rather than lose it permanently.

Site-wide Organization schema and the founder Person schema go in Settings > Advanced > Code Injection > Header. Both fire on every page. Article schema goes per-post. BreadcrumbList schema is per-page and follows the breadcrumb trail Squarespace displays (or that the site implements via Code Injection if Squarespace's native breadcrumbs are not active). The BreadcrumbList schema leaf in Pillar 3 covers the per-page block.

The cutover sequence

Cutover day: point the domain at Squarespace, wait for DNS propagation (4 to 24 hours), submit the URL Mappings list (which was authored on the staging site beforehand), submit the new sitemap to Google Search Console, file the change-of-address request if the domain itself changed (e.g. yoursite.wordpress.com to yoursite.com), and monitor intensively for 48 hours. WordPress sites with Yoast were typically running clean sitemaps already, so the new Squarespace sitemap is the only new submission Google needs.

One WordPress-specific detail: WordPress's default robots.txt sometimes contained Disallow rules for /wp-admin/ and other internal paths that no longer exist on Squarespace. Squarespace's auto-generated robots.txt does not carry those rules forward, and the absence is correct — there is no /wp-admin/ on Squarespace to disallow. No action needed on the operator side. Search Console will report fewer disallowed URLs after migration, which is the right outcome.

Post-cutover monitoring and the long tail

Watch Search Console daily for the first 14 days. The Coverage report's 'Not found (404)' count should be near zero by day 7. The Performance report's impressions and clicks dip in the first 14 days (normal) and start recovering by day 30 to 45. Top-traffic URLs typically recover their rank position by day 60 to 90; long-tail URLs take 120 to 180 days. The recovery is steeper when the schema rebuild is complete and the heading hierarchy patch is shipped on collection pages.

Google's documentation4 emphasises patience: "The move can take a while." For a typical WordPress-to-Squarespace migration of a 50-post blog, the recovery window is 90 to 120 days. For a 500-post blog, plan for 6 to 9 months for the long tail to fully recrawl and rerank. The traffic-drop diagnostic leaf covers the in-flight monitoring playbook.

Keep reading · § 2.11.2