DEV Community: Juan Carlos Rodicio

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.