DEV Community: Juan Carlos Rodicio

We followed the redirects of 15 big sites: 12 of 30 start URLs took two hops or more

Juan Carlos Rodicio — Thu, 05 Nov 2026 13:58:28 +0000

After a migration, people check that old URLs “redirect”. That is a weaker test than it sounds. To see what a real result looks like, we ran a plain HTTP request (curl, following redirects, 15 s timeout) on 5 November 2026 against the http:// and http://www. forms of 15 well-known domains: 30 start URLs.

What came back

Result	Start URLs (of 30)
One 301, ending on a 200	12
Two to three hops before the final page	12
First hop was a 302 (temporary)	2 (mozilla.org, www.bbc.com)
Blocked with a 403 on the first request	3 (weebly.com, www.weebly.com, www.nytimes.com)
Redirected, then a 403 on the final page	2 (medium.com, www.medium.com)

The 12 two-hop cases are mostly www.example.com → example.com → https://…, or http → https → www: the host and the protocol are fixed in separate steps. Notion took three hops from notion.so to notion.com, and stripe.com ended on a localized /fr page, chosen by the server from where we were, not by the URL we asked for.

What this means for a migration check

Count hops, don't just look for a 301. A chain of two or three 301s works for visitors, but each hop is another place for a rule to break. Most of the multi-hop results here came from the www/https combination, which a migration changes without anyone noticing.
Check the status of the first hop. Two of 30 started with a 302. For a page you have moved for good, a 302 says “temporary”. Many hosts and plugins default to it.
Check the last page, not just the redirect. A redirect that lands on a 404 is the failure that costs you traffic. The Medium case shows the opposite trap: the redirect is fine but the final page refuses a script. A 403 from a bot filter is not the same as a broken page, so a checker should say “blocked”, not “failed”.
Test the www and http forms of the new domain too. Old links in the wild use all four combinations.

Limits of this sample

Fifteen large sites, one request each from one server, one day. Big sites are not small migrated blogs, and results from a CDN can vary by location. We did not test deep URLs, only domain roots. It is a way to see what the common shapes look like, not a survey.

Run it on your own list

The free redirect checker follows each old URL and flags missing redirects, temporary (302) redirects, and landing pages that don't return 200. Paste your list (CSV, _redirects, .htaccess) and the new address. For a Wix move the usual gaps are described in the Wix 301 limits and the URLs your redirect map forgets.

Originally published at https://decamp.app/notes/redirect-chains-in-the-wild

301 redirects on Wix: the 5,000 limit, the homepage rule, and the blog gap

Juan Carlos Rodicio — Wed, 04 Nov 2026 15:16:15 +0000

Wix has a redirect tool, the URL Redirect Manager, and it is easy to assume it will carry a blog move. It can carry part of one. Here are its limits, taken from Wix's help page “Setting up 301 redirects” as we read it on 4 November 2026.

What the help page says

5,000 redirects per site. The page says “You can create a maximum of 5,000 redirects per Wix site.”

Custom domains only. You can't redirect from a free Wix address (name.wixsite.com/…) to a Premium site.

No redirect from the homepage in the manager. Wix points to a domain-to-domain redirect for that case.

No source link with a # in it.

A few minutes before a new redirect takes effect.

Deleted redirects “cannot be recovered.” Keep your list in a file you control.

Group redirects exist for many pages that share a path, such as product pages or blog posts. The page doesn't say whether wildcards are supported, so test one before you rely on it.

The blog gap

When you change a page's slug after publishing, Wix creates a 301 for you. The page lists where that applies: Editor pages, Stores product and category pages, Bookings services, Online Programs and Wix Events. Wix Blog pages are not on the list, and the page says they get no automatic redirect, so you must create one manually. For a blog that matters twice: renaming a post doesn't protect its old link, and a blog with more than a few thousand posts, categories and archive pages can reach the 5,000 ceiling on its own.

Where this tool stops being useful

The manager only works while the domain is still connected to Wix. If you move the domain to WordPress, Ghost or Webflow, Wix is no longer answering for it, so its redirect list does nothing. The redirects have to live on the new host: a _redirects file, an .htaccess, a plugin, or the platform's own redirect panel. Two cases where the Wix manager still helps:

You keep the old Wix site running on its domain for a while and send selected paths to a new domain. The help page allows an external page as the target if you enter the full URL.
You rebuild inside Wix and change slugs. Automatic redirects cover pages and products, but not blog posts.

A checklist

List every URL from the sitemap, not from the RSS feed (see the Wix URLs your redirect map forgets).
Count them. If the list is near 5,000, plan for pattern rules on the new host instead of one-by-one entries.
Decide the homepage case separately; it can't be a single redirect in the manager.
Save the list as a file before you delete anything in Wix.
After the switch, run the old URLs through the redirect checker: each should be one 301 to a 200.

Originally published at https://decamp.app/notes/wix-301-redirects-limits

Squarespace to Webflow: what the export hands you, and why Webflow can't read it

Juan Carlos Rodicio — Tue, 03 Nov 2026 13:19:34 +0000

“Squarespace to Webflow” is the search that brings most people to Decamp's guides, and the reason is a format mismatch: Squarespace exports one kind of file and Webflow imports another. This note is what Squarespace says its export contains, read from its help page on 1 November 2026, and what that means for a move.

What you get from Squarespace

Settings → Export gives you a WordPress-format XML file (Squarespace help: Exporting your site ). Per that page, it includes:

layout pages, and gallery pages (project pages of the older York template only on version 7.0);
one blog page with its posts and up to 1,000 comments per post;
image blocks and text blocks, plus text from embed and Instagram blocks with minimal structure.

What it leaves out

Every blog but one. Only one blog page exports, and you choose which. A site with a blog and a news section loses half of its posts unless you run the export twice, and the second run replaces the first.

Other page types: album, cover, index, info, calendar, portfolio and store pages.
Content in page-specific headers, footers and sidebars.
Product blocks, audio blocks, video blocks, dropdowns and drafts.
Style settings and Custom CSS. Webflow was always going to be a redesign; this confirms nothing visual comes along.

Why Webflow can't use the file

Webflow's CMS imports CSV files into a collection, one row per item, and fetches images from the URLs in the file during the import. It does not read WordPress XML. So the usual route is to turn the XML into a CSV with a rich-text column, which means handling the HTML in each post, finding the cover image, and mapping categories and the SEO description. Tools exist for that conversion, and so does copying posts by hand; what matters is that the step exists and that the XML is its only input.

Two consequences. First, any image the importer fetches must still be reachable at import time, so keep the Squarespace site alive until the import has finished and you have checked the pictures in Webflow. Second, whatever the XML does not hold (the second blog, the other page types, product pages) has to come from somewhere else.

The URLs

Squarespace blog posts usually live at /blog/<slug> (the path depends on the name of your blog page). Webflow collection items live under the collection's own path, which you choose. If you keep the same path, much of the redirect list is empty; if you don't, every old URL needs a 301 in Webflow's hosting settings. Build the list before the domain switches. See the same problem on Wix.

Checklist before you switch

Count your blog pages. If there is more than one, plan for the others separately.
List the pages of types the export drops (index, portfolio, album, store) and note which ones you need to rebuild.
Decide the Webflow collection path first; it fixes your redirect map.
Import while the old site is live; check images and links in the Webflow editor before cancelling.
Export store products separately: see what the product CSV leaves out.

Decamp reads the published Squarespace site instead of the XML, so every blog page comes through, and it writes the Webflow CSV and the 301 list. The inventory is free. See the Squarespace to Webflow guide.

Originally published at https://decamp.app/notes/squarespace-to-webflow-what-moves

Transferring Wix to WordPress: what actually transfers, and the three ways people try

Juan Carlos Rodicio — Tue, 03 Nov 2026 13:19:33 +0000

“Transfer Wix to WordPress”, “move Wix to WordPress” and “transfer from Wix to WordPress” are the searches that show Decamp's guide in Google without anyone clicking. The honest answer to all three starts with a sentence from Wix itself.

What Wix says

Wix's help page on the request reads: “Currently, it is not possible to export blog posts to other platforms.” It is filed as a feature request with no date (Wix help, read 2 November 2026). The page's only suggestion is sharing posts on social media. Whatever a guide calls a “transfer”, it is a workaround.

The three workarounds

1. The RSS feed

The popular tutorial: take the blog's RSS feed and load it with WordPress's RSS importer. When we looked at Wix feeds in October 2026 they carried the 20 latest posts and, for current blogs, links rather than full text. A blog with 141 posts would come over as 20 stubs. Images in whatever text does arrive still point at Wix's servers, and WordPress does not copy them into your media library on its own.

2. Copy and paste

Reliable and slow: open each post, copy it, paste it into the WordPress editor, re-upload the images. It is fine for 15 posts. At 141 posts and 733 images (the size of one real Wix blog we exported) it is days of work, and the order and dates are yours to fix.

3. Read the published site

A Wix blog is public, so the posts, with full text, categories, tags and SEO fields, can be read the way a visitor's browser reads them and written into a WordPress import file (WXR) with the images attached. That is what Decamp does. In our tests the file imported into a real WordPress with images in the media library; the exception is anything a published page does not expose.

What does not transfer, whichever way you go

The design. WordPress means choosing a theme; nothing visual carries over.
Stores, bookings, member areas and forms. These are Wix apps, not content (products have their own CSV: what it leaves out).
Comments, in most routes.

Before the domain moves

Count posts, pages and images first, so you know which route is realistic.
Keep Wix alive until you have checked the imported images and links in WordPress.
Wix post URLs look like /post/<slug>; WordPress uses its own permalink structure. Either match it or write 301 redirects, or the old links in Google 404. See the Wix URLs a redirect map forgets.

The inventory is free. See the Wix to WordPress guide for what the paid export contains.

Originally published at https://decamp.app/notes/wix-to-wordpress-what-transfers

Exporting a Webflow site you don't own the Workspace for: what a 62-post CMS looks like from the outside

Juan Carlos Rodicio — Sat, 31 Oct 2026 18:33:23 +0000

A published Webflow site is static HTML, and the CMS leaves marks in it. We ran an export against a public Webflow site (marketing.flowbase.co) on 31 October 2026 and read the files that came out: 62 posts, 21 pages, 577 images (~94 MB), and 229+ other CMS items that are not posts.

What the HTML tells you

data-wf-site on <html> marks every Webflow page; data-wf-collection and data-wf-item-slug mark CMS items. The sitemap gives the list: /<collection>/<slug>.
Nothing says which collection is the blog. Here two collections read like blogs. Our rule: names like blog/posts/articles/news, else the largest collection. It's a heuristic, so the scan lists the other collections instead of hiding them.
Dates are a design decision: 33 posts had one, 29 help articles showed none, so only the sitemap's lastmod (last publish, not first) is left.
The body is the largest .w-richtext element; -p-500 resized image copies map back to the original file.
The same newsletter block was repeated on 16 pages, with its images each time. Short sections containing a form are now dropped.

What a visitor's view can't give you

Categories/authors/tags (CMS references), forms, e-commerce, memberships, code embeds, layout, drafts.

Full write-up with the checklist: https://decamp.app/notes/webflow-cms-export

What Weebly's archive leaves out: a 34-post blog, comments and uploaded files

Juan Carlos Rodicio — Tue, 27 Oct 2026 14:19:19 +0000

Weebly has one export, and its help page says what is missing: "Blog and store pages aren't included in the export as they rely directly on our database." (Weebly help). The archive is a ZIP of static pages. For most Weebly sites the blog is the part worth keeping.

So we read a public Weebly blog the way a visitor's browser does, then imported the result into a real WordPress to see what survived. The site is jess-ambers-blog.weebly.com, tested in October 2026. These are the numbers and the traps.

The inventory

34 blog posts and 5 pages
235 images, which with the 5 files below make 240 attachments in WordPress
28 comments on the posts
5 uploaded files (zip, xlsx, pdf and docx) linked from the text

None of this is behind a login. Classic Weebly renders everything on the server, so the HTML a visitor gets contains the posts, the dates and the comments.

1. Posts and pages look alike in the sitemap

Pages always end in .html. Posts don't: they live at /<blog>/<slug>, with no extension. That is the only reliable way to tell them apart from the URL list:

/about.html                      page
/blog/my-first-post              post
/blog/my-first-post-2            post

The sitemap is also not in date order. If you want the newest posts first, or a preview of what a site contains, you have to read the blog's listing page, which shows the latest entries, instead of trusting the order of the file.

2. Dates come in two formats

A post's date is printed as text in the site's own style: 7/15/2019 on one site and 15/7/2019 on the next, or July 15, 2019. For the first two, the day and month are ambiguous whenever both are 12 or less. What settles it is the share links on the page: they carry the old /N/post/YYYY/MM/ address, and that month tells you which number is the month. Without that check, posts silently move to the wrong month.

3. Comments are in the HTML, if you ask for them

Approved comments sit in the post's HTML (.blogCommentWrap, with author, date and the reply it answers). Weebly's archive ignores them along with the blog. Copying posts by hand loses them too, because they are not part of the post body. We read 28 comments across the 34 posts and wrote them into the WordPress file as real comments with their thread order, not as text at the bottom of the post.

4. Images: the resized copy and the original

Weebly stores uploads under /uploads/a/b/c/d/<id>/ on the site's own domain, and the files answer requests from a browser on another site. The picture in a post is often a resized copy, name.jpg; when you click it, it opens name_orig.jpg, the file as uploaded. The <a> around the image points at the original, so that is the address to save. Add a ?1563249199 cache-buster to the end and the same file looks like a different URL; strip it.

5. The uploaded files are the ones people forget

Posts also link to documents hosted on Weebly (here a zip, a spreadsheet, a PDF and a Word file). They are not images, so an image-only copy leaves five links pointing at Weebly's servers. We saved them to a files/ folder and added them to the WordPress file as attachments.

Result of the import into a real WordPress: 34 posts, 5 pages, 240 attachments, 28 comments, no "already exists" skips, and 0 links left pointing at weebly.com/uploads. On repeated file names, see the "already exists" trap in our first note.

6. Weebly is now two products

"Weebly" today also means Square Online, the newer builder. It draws the page in the browser, so there is no blog markup in the HTML to read. Everything above is about classic Weebly sites. If a site is on Square Online, tell the owner up front rather than returning an empty export.

A checklist before you copy anything

Posts are URLs without .html; pages are the ones with it.
Read each blog's listing page for the newest posts; the sitemap order means nothing.
Check dates against the /N/post/YYYY/MM/ share link before trusting M/D versus D/M.
Keep the comments: they are in the HTML and not in any archive.
Save _orig images, not the resized copies, and strip the numeric cache-buster.
Save uploaded documents too, or the new post links back to Weebly.

Decamp does all of this for classic Weebly sites and writes WordPress, Ghost, Webflow, Framer and Markdown files plus the redirects. See exporting a Weebly blog or Weebly to WordPress.

Inside a Jimdo Creator site: what an export has to read

Juan Carlos Rodicio — Wed, 21 Oct 2026 13:14:21 +0000

Jimdo is plain about it: "At Jimdo, there is also no option for creating a backup of your website yourself." (Jimdo help). No blog export, no XML file, no ZIP. If you want your content somewhere else, the published site is the only copy you can read.

So we read one: a public Jimdo Creator blog, a German-language news blog with posts from 2010 to 2013. Here's what a Creator site looks like from the outside, and what trips up anyone copying it, by hand or with a script.

1. The sitemap is the inventory

/sitemap.xml lists 1,615 URLs in one file. 1,202 are blog posts, easy to spot because the date is in the path:

/2012/12/31/die-besten-wünsche-zum-jahreswechsel-…/   post
/2012/12/30/hinweise-zum-grenzüberschreitenden-…/   post
/startseite/                                        page
/archiv-info24-blog24/                              page
/dezember-2013/                                     page (a monthly archive)

The other 413 are pages, many of them archive or category pages built by hand. There are no <lastmod> dates. The RSS feed (/rss/blog) has 18 items: fine for a reader, useless as a list of everything you wrote.

2. A page is a stack of modules

Creator renders every page server-side as a column of j-module blocks inside #content_area. One post from December 2012:

j-header          4   headings
j-text            8   paragraphs
j-textWithImage   8   a paragraph with a floated image
j-hr              5   dividers
j-spacing         2   empty space
j-facebook        1   ┐ from the template sidebar,
j-rss             2   ┘ not from the post

Read only #content_area, or every post picks up the sidebar widgets. And map each module type deliberately:

Column grids (j-hgrid) hold other modules. Skip nested modules and you drop whole columns; read them column by column.
Tables (j-table) are real HTML tables. Treat them as layout and they vanish: one post we tested went from three tables to one.
Downloads (j-downloadDocument) link to PDFs under /app/download/ on the Jimdo domain. Those links die with the site.
Tags sit inside the post area. Copy it as text and every post ends with a line of tag names; extract them as tags.

3. Every image is called image.jpg

The post loads 30 image URLs. Two are the template's header and favicon; of the other 28, 25 end in image.jpg and three in image.gif. The path is what tells them apart: a file ID plus the size Jimdo resized it to.

image.jimcdn.com/app/cms/image/transf/dimension=210x1024:format=jpg/path/…/image/i8d39…/version/1356172872/image.jpg
image.jimcdn.com/app/cms/image/transf/none/path/…/image/i8d39…/version/1356172872/image.jpg

The page asks for ten different dimension= values, mostly 210–320 px wide. Replace the transf/… segment with transf/none to get the file as uploaded; save the thumbnail and the new site gets a blurry 210-px image.

The shared name causes a second problem: saved by name, images overwrite each other, and the WordPress importer may skip most of them as "already exists" (it compares titles), leaving posts hot-linking Jimdo. We hit exactly that in testing (37 images on one Jimdo site). Fix: a unique name per image.

4. Creator is not the new Jimdo

Jimdo runs two builders. The newer one has no blog, and "The content on your Creator website can't be moved over to your Jimdo website." (Jimdo help). Leaving Creator means leaving Jimdo, or rebuilding by hand.

Checklist

Count posts from the sitemap (date in the path), not the feed.
Read #content_area only, module by module, including inside column grids.
Swap every image to transf/none and give each file a unique name.
Save PDFs from /app/download/ links.
Keep the old dated post URLs for your redirect map.

I build Decamp, which exports Jimdo Creator (and Wix, Squarespace, GoDaddy, Weebly) sites to WordPress, Ghost, Webflow, Framer and Markdown with redirects. Originally published at decamp.app/notes.

The Wix URLs your redirect map forgets

Juan Carlos Rodicio — Tue, 20 Oct 2026 07:35:25 +0000

When people move a Wix blog, they redirect the posts: /post/my-title to wherever the post lives now. That covers the URLs you think of. Google has indexed more than that, and every one you don't map turns into a 404 the day the domain moves.

Here is what a real Wix site exposes, using one we checked this week: a design studio's blog with 356 posts, a shop and some dynamic pages. The patterns are the same on any Wix site.

1. Start from the sitemap, not the feed

/sitemap.xml on a Wix site is an index that points to one sitemap per content type. On this site there were nine:

blog-posts-sitemap.xml        356 posts at /post/<slug>
blog-categories-sitemap.xml   /blog/categories/<slug>
pages-sitemap.xml             /blog, /portfolio, /about…
store-products-sitemap.xml    /product-page/<slug>
store-categories-sitemap.xml
pricing-plans-sitemap.xml     /pricing-plans/list
member-profiles_…-sitemap.xml
dynamic-…-sitemap.xml         (two CMS collections)

The RSS feed (/blog-feed.xml) on the same site lists 20 posts. It's a feed of recent items, not an inventory, so a redirect list built from it misses 336 posts here. Large blogs also split the posts sitemap into pages, so follow the nested index too.

2. Category archives

Every blog category has its own URL, /blog/categories/<slug>, and Wix lists them in the sitemap, so they get indexed and collect links. The slug is Wix's, not necessarily the category name: a category called "Women in Business" can live at /blog/categories/womeninbusiness.

Point each one at the matching archive on the new platform: /category/women-in-business/ on WordPress, /tag/women-in-business/ on Ghost, or the blog index where the platform has no category pages.

3. Paginated blog pages

/blog/page/2, /blog/page/3 and so on answer with a 200 and a canonical tag pointing at themselves, so Google can keep them. Their numbering won't match the new blog, so send them all to the blog index with one pattern rule:

# Netlify / Cloudflare Pages (_redirects)
/blog/page/*  /blog/  301

# Apache (.htaccess)
RedirectMatch 301 ^/blog/page/[0-9]+/?$ /blog/

# Nginx
location ~ ^/blog/page/[0-9]+/?$ { return 301 /blog/; }

4. The old /single-post/ links

Older Wix blogs served posts at /single-post/… before the switch to /post/. Links from that era are still out there in old articles, forum threads and newsletters. On the site we checked, /single-post/<slug> already returns a 404 on Wix itself, so those visitors are being lost today. A move is a chance to win them back: map /single-post/<slug> to the new post as well.

5. Exact paths: slashes and capitals

Wix answers /post/my-title/ with a 301 to the version without the trailing slash, and /Post/my-title with a 404: paths are case-sensitive. WordPress and Ghost add trailing slashes. Keep the old side of each redirect exactly as Wix wrote it, and the new side exactly as the new platform does, or the redirect chains through an extra hop or misses.

6. Things that aren't posts

Products live at /product-page/<slug>. If the shop moves to Shopify or WooCommerce, map them to the new product URLs; if it closes, to the most relevant page.
Pricing plans, member profiles and dynamic CMS pages each have their own sitemap. Decide per collection: rebuild, redirect to a parent page, or let them go.
Images are served from static.wixstatic.com, a Wix domain you can't redirect. Image search traffic only survives if the images are re-hosted on the new site with their alt text, before the Wix plan ends.
Free addresses (name.wixsite.com/site) can't carry redirects at all. Only a custom domain can, which is one more reason to connect the domain to the new host rather than start fresh.

Check it after the switch

Once the domain points at the new host, run the old URLs through a checker and look for anything that isn't a single 301 to a 200. A free redirect checker does that for a pasted list, and the Wix redirect map tool builds the list from a live Wix sitemap.

Disclosure: I build Decamp, which exports Wix sites and writes these redirect files (category archives and the old /single-post/ links included).

Getting content out of Wix, Squarespace, GoDaddy and Jimdo: what actually works in 2026

Juan Carlos Rodicio — Mon, 19 Oct 2026 07:45:18 +0000

Most website builders don't really let you leave. Wix's help centre says blog posts "can't be exported to other platforms". Squarespace exports one blog as a WordPress file, with images left as links that, in its own words, "stop working after you cancel". GoDaddy's builder backups exclude blogs and images. Jimdo says there's "no option for creating a backup of your website yourself".

We build Decamp, a tool that exports those sites, so we spend our days reading what these platforms publish. Here's what we learned, including two bugs that would have silently lost our users' content.

Read the data the platform already serves

Scraping rendered HTML gets you layout soup. Each builder serves something better:

Wix: the public site issues a visitor token (/_api/v1/access-tokens) that the Wix Blog API accepts. Posts come as "Ricos", a structured rich-content JSON (paragraphs, lists, galleries, tables, embeds), which converts cleanly to HTML. Static pages render server-side if you ask with ?forceSsr=true.
Squarespace: append ?format=json to any collection or item URL and you get the item body plus metadata.
GoDaddy Website Builder: blog posts are embedded in the page as Draft.js JSON (window._BLOG_DATA).
Jimdo Creator: pages are server-rendered stacks of j-module blocks, one class per module type.
Weebly: classic sites are server-rendered too (#wsite-content, .blog-post), approved comments included, and uploads live under /uploads/ on the site's own host with open CORS.

Gotcha 1: WordPress silently skips images that share a title

We generate a standard WXR file and let WordPress's own importer pull the images. In a real import, Jimdo sites lost 37 images and GoDaddy sites 20, with no error. The importer treats any item whose title (plus date, when there is one) matches an existing post as "already exists" and skips it. Every Jimdo image is called image.jpg; pages have no date; and a cover image's alt text often equals the post title. Skipped attachments mean the post keeps hot-linking the old site, which breaks the day the subscription ends.

Fix: unique titles for every attachment across the file, and distinct timestamps for undated items. Same content, zero skips.

Gotcha 2: Squarespace "website component" blocks

Newer Squarespace sites wrap blocks like this:

<div class="sqs-block website-component-block sqs-block-website-component sqs-block-markdown">

If you take the first sqs-block-* class as the type, every block becomes "website-component". On one podcast site that dropped entire episode transcripts (350 words exported instead of 7,633), dropped the audio players, and let "related posts" grids slip in as content. Take the first class that isn't website-component.

Smaller lessons

Images: export files, not links. And PNG photos from Wix at 2048px weigh 4 to 6 MB; WebP copies keep transparency at a third of the size.
Big WordPress imports time out on shared hosting. Splitting the WXR into 100-item files (with shared titles and dates so a re-import still dedupes) fixes it.
Comments are reachable: Wix through its comments service (keyed by the blog's internal post id), Squarespace through a public endpoint. Sanitize them: visitor HTML goes straight into WordPress, and the importer doesn't filter it.
Redirects: generate them for every host (Redirection plugin CSV, .htaccess, Nginx, Netlify _redirects, Vercel, Ghost YAML, Webflow, Squarespace URL mappings), then check them after DNS moves. We built a free checker for that: decamp.app/tools/redirect-checker

If you're moving a site off one of these builders, Decamp (decamp.app) does all of the above; the inventory and preview are free. Happy to answer questions about any of the internals in the comments.