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

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.