Publishing sites built in the Code IDE

Code IDE sites publish through the same pipeline as legacy workbench sites — same slug-based URLs (your-slug.itzseo.com), same custom-domain flow, same snapshot history. What’s different is how the publishable bytes are assembled.

What the publish step does

Click Publish from the legacy workbench view of an IDE site (the IDE’s own Publish button is a placeholder — that surface lands in a later phase). The server reads your DesignFile tree and stitches it into the standard publish snapshot:

Each pages/*.html becomes one page on the published site. The slug comes from the filename (pages/about.html → /about), the page name from <title>, and the body content from the document’s <body>.
Every styles/*.css file is concatenated into a single CSS blob the renderer inlines in <style>. Cross-file comment headers (/* path */) keep it debuggable.
Every scripts/*.js file is concatenated into a single JS blob inlined at the end of <body>.
If you don’t have a pages/index.html, the first page in path order is promoted to the homepage slug so / doesn’t 404.

Recommended workflow

Build in the IDE with the agent’s help. Run ▶ Preview from the topbar to see the current state in a new tab.
When ready, click ↩ Classic to switch this site back to the legacy workbench.
Click Publish in the legacy workbench top bar. Pick a slug if it’s the first publish, or confirm the existing one to republish.
Your site is live at your-slug.itzseo.com within seconds. The classic workbench preview can stay offline; only the publish step copies bytes out.

You can stay on the IDE surface and publish via the legacy URL too — switching to legacy first is just a visual cue that the Publish button you’re clicking lives there.

Current limits (v1)

Binary assets in public/ (PNG/JPG/SVG files) aren’t served from their canonical URLs yet. A page that references /images/logo.png won’t find it. Workaround: paste images as data URIs into the HTML, or host them elsewhere (Imgix / Cloudinary / your CDN) and reference the absolute URL.
_partials/ don’t ship as their own URLs, but they ARE used at publish: _partials/header.html and _partials/footer.html render on every page via @include, and _partials/head.html injects into every page’s <head>.

Site-wide `<head>`, CSS & JS

These all work in the Code IDE (no need to flip back to the legacy workbench):

Custom <head> snippets — GA / GTM, Meta Pixel, search-engine verification, the Tailwind CDN, web fonts, schema.org JSON-LD: create config/custom-head.html (or _partials/head.html) and its contents are added to every page’s <head> on publish. You can also paste site-wide head markup into the Custom HEAD field in the Publish dialog.
Site-wide CSS — any file under styles/ bundles into every page.
Site-wide JS — any file under scripts/ bundles into every page (split your JavaScript across several files; they concatenate at publish).

Determinism

Two publishes of the same site, with no edits between them, produce byte-identical snapshots. The build sorts files on (kind, position, path) so the output is stable. Useful when reviewing publish diffs in the snapshot history.