Import from Google Sites

DocuCommit reads a Google Sites export and writes an ordinary project into your working copy: one Markdown file per page, images and linked files in _attachments/, frontmatter filled in. The import runs in the editor and commits nothing. You review the result and publish it like any other change.

1. Export the site from Google Takeout

Sign in with an account that can view the site, go to takeout.google.com, select Google Sites and nothing else, and create the export. Google sends a download link when the archive is ready.

What comes back is a ZIP of HTML: one .html file per page, plus the images and files those pages reference. That is exactly what the importer consumes — every .html and .htm file it finds anywhere under the export, and any asset those pages point at.

2. Run the import in the editor

On the library home, open Import Google Sites in the Actions panel. There are two routes, and they do the same work.

From a ZIP export. Fill in Project name, choose the Export ZIP, and select Import ZIP. The upload is capped at 200 MB by default; the limit is DOCUCOMMIT_LOCAL_MAX_UPLOAD if you need to raise it.

From an unzipped folder. Unzip the archive yourself, fill in Project name, put the folder in Export folder path (or use Browse…), and select Import folder. No upload limit applies on this route, which makes it the better one for a large site.

Both forms carry Auto-generate tags from page content, on by default. Both need a Project name that contains at least one letter or digit, and that does not match a project you already have.

If the export unpacks into a wrapper folder (or several nested ones), you can point at the outer folder. The importer descends through single-child folders until it finds the HTML.

On success the editor opens the new project.

What the importer produces

In the export	In your repository
The site’s navigation menu	The project’s section and page tree
A page’s HTML body	A Markdown document
<pre> / <code> blocks	Fenced code blocks, with the language when the markup declares one
Layouts built from <div>s and ARIA table roles	Real Markdown tables
<img> sources and CSS background-image URLs	Files in the project’s _attachments/
Links to non-HTML files	Files in the project’s _attachments/
Links between pages	Wiki links that point at the target document’s uuid
Page titles	title in frontmatter, with the repeated site name trimmed off

Details worth knowing:

• Hierarchy comes from the site’s own navigation. A top-level nav entry that has children becomes a section; one without children becomes a page at the top of the project; deeper nav levels nest as sections. For a page the navigation does not mention, the folder it sits in inside the export decides, and a file called index.html or home.html becomes that section’s landing page.
• Every project and section gets an index.md. A section whose site had no landing page of its own gets a generated one.
• Google Sites chrome is stripped first — scripts, styles, headers, footers, navigation bars, breadcrumbs, cookie notices — so the Markdown holds the page, not the theme.
• Attachments are de-duplicated by content. Every file is hashed with SHA-256 before it is written, so a logo that appears on forty pages is stored in _attachments/ once and all forty pages point at that single copy. File names are lowercased and cleaned up on the way in.
• Internal links become wiki links of the form [[Page title|uuid]]. Because they resolve by uuid rather than by path, they survive later renames and moves.
• Embedded frames are kept as HTML in the page, so a video, map, or calendar embed still renders.
• Images the export references but does not contain — remote URLs — are left pointing at the remote URL.

Frontmatter it writes

Each imported page gets title, slug, uuid, and sort. Section landing pages also get type: index. With auto-tagging on, pages also get tags, drawn from the project name, the section name, any keywords meta tag in the exported HTML, and up to six weighted terms from the page itself (image alt text and headings count for more than body text). Turn the checkbox off if you would rather tag by hand. See Repository layout for what each field does.

When something does not resolve

An image whose file is missing from the export, or a link whose target page cannot be matched, is recorded as a warning and the import carries on. The page is still written; the image or link is simply left as it was. Warnings never fail an import.

When the import stops

Some conditions stop the import before anything is written:

Condition	What you see
A project with that name already exists	A project with that name already exists.
The project name has no letters or digits	Please enter a project name with at least one letter or number.
No content directory configured yet	No content directory is configured. Set one in Settings first.
The ZIP cannot be read	That file could not be read as a Google Sites export ZIP.
No HTML pages found in the export	No Google Sites pages were found in that export.

The project name must be new because the importer refuses to write into an existing project folder. Rename the target, or rename the folder you already have.

If a page fails while the project is being written, the whole new project folder is deleted and the import reports failure. There is no half-imported project to clean up. ZIP entries that try to escape the extraction folder, and any output path that would land outside your library, are rejected outright.

Limits, stated plainly

• Google Sites is the only importer. There is no Confluence, Notion, or generic HTML import. Coming from Confluence, the practical route is exporting to HTML and converting with pandoc — that path is written up here.
• The import runs in the editor, not on the server. The server only reads what your repository already contains.
• Nothing is committed automatically. The import writes files to your working copy, exactly like saving a page does. Read the result, fix what the conversion got wrong, and then Publish. A large import is worth reviewing before it becomes a commit.