Skip to content

Start building your next app or website — with AI, right in your browser.

Visit devdojo.com
Docs
Publishing

Sites 12 / 13

Publishing

Preview privately, publish instantly to your own URL, and export a ready-to-host copy of your site anytime.

Publishing

Your site has two lives: the private preview only you can see while building, and the published site the world sees. Here's how they fit together — and how to take your work with you.

Preview privately

The preview pane in the builder is your actual site, rendered live. Save a file and it refreshes. Only you can see it — preview URLs require you to be signed in, so half-finished pages stay between you and the editor.

  • Check every width: drag the preview's edge handles (a width badge follows along) or press 1 / 2 / 3 for desktop, tablet, and phone.
  • Want the full-browser experience? Open the canvas's ⋯ Preview options and use Open in new tab.

Publish

When you're ready, click the blue Publish button in the top bar. Your site goes live at its own address, built from your site's slug:

https://your-slug.devdojo.site

The first time you publish, the builder asks you to choose your URL: the field holds your site's current slug with .devdojo.site beside it — keep it or type the address you want, then hit Publish. You can change it any time later in the Settings panel, where the slug also appears alongside your publish status.

The site settings panel with publish state and URL

Two things worth knowing:

  • Publishing is instant. No build queue, no waiting.
  • Everything travels together — every page, plus anything in public/ (like your robots.txt, which is served from your site root). Your CSS ships too, inlined into each page.

A published site in the browser

Once you're live

The Publish button becomes a Live menu:

  • Republish changes — pushes your latest saved edits to the live site. Keep building, then republish whenever you want the world to catch up.
  • Unpublish — takes the site offline.

Unpublishing is instant and non-destructive. Visitors get a 404 right away, but nothing is deleted — everything is still in the builder, and publishing again brings the site right back.

Custom domains

Want to serve your site from a domain you own instead of the .devdojo.site subdomain? Open Settings → Domains on your site, add the domain, and follow the two DNS records it shows you. Once it's verified, your published site serves from your domain automatically — the included your-slug.devdojo.site address keeps working too.

1. Add the domain

Type the hostname you want to serve from — blog.example.com, www.example.com, or the bare example.com. Leave off https:// and any path; we normalize what you paste.

2. Add two DNS records at your registrar

The moment you add the domain, Settings shows you the exact records to create. They look like this:

Type Name Value
TXT _devdojo.blog.example.com devdojo-verify=…your token…
CNAME blog.example.com sites.devdojo.site

The TXT record proves you own the domain. The CNAME points traffic at us. Copy them exactly as shown in Settings — the token is unique to your site, and it's reissued if you remove and re-add the domain.

Where do these go? Every registrar calls it something slightly different — "DNS", "DNS records", "Manage DNS", or "Zone editor". Some registrars append the domain for you: if the Name field already ends in example.com, enter just _devdojo.blog instead of the full _devdojo.blog.example.com.

3. Click Verify

Once the TXT record is live, hit Verify in Settings. We look the record up and flip the domain to verified.

DNS usually propagates within minutes, but registrars are allowed to take up to 24 hours. If Verify fails, wait a few minutes and try again — nothing is lost, and you can click it as many times as you like.

Apex domains (example.com with no subdomain)

Most registrars won't let you put a CNAME on a bare apex domain — it's a DNS restriction, not one of ours. Two ways around it:

  • Use a subdomain (recommended). Point www.example.com at us with a CNAME, then use your registrar's redirect/forwarding feature to send example.comwww.example.com. This is the simplest setup and works everywhere.
  • Use your registrar's flattened CNAME, if it has one. Cloudflare calls it CNAME flattening, others call it ALIAS or ANAME. Create that record type at the apex with the same value, and it behaves like a CNAME.

The TXT verification record is a normal record and works at the apex either way.

Once it's verified

  • Your published site serves from your domain.
  • Your domain becomes the site's canonical address: it's what sitemap.xml and the generated robots.txt point at.
  • Republishing doesn't change anything. The domain stays attached across publishes.

Removing a domain

Hit the remove button next to the domain in Settings. It stops serving your site immediately. You can add it back later (you'll get a fresh TXT token to verify with), and your .devdojo.site address is unaffected throughout.

When something isn't working

  • "That domain is part of the platform" — you entered a devdojo.site address. Custom domains are for domains you own; your platform subdomain is already set up under Included subdomain.
  • "That domain is already connected to a verified site" — the hostname is verified on another site. Remove it there first.
  • Verify keeps failing — check the TXT record's Name field. The most common cause is a doubled domain (_devdojo.blog.example.com.example.com) from a registrar that appends the domain automatically.
  • Verified, but the domain doesn't load — the CNAME is missing or still propagating. Verification only reads the TXT record; the CNAME is what actually routes visitors.

SEO out of the box

Every publish — and every export — ships with the two files search engines look for first:

  • robots.txt — a permissive default that welcomes crawlers and points them at your sitemap.
  • sitemap.xml — every page of your site at its clean URL (/, /about, /blog), with last-modified dates, built from the same pages you see in the builder.

You don't have to do anything — they're generated automatically from your site's live URL, so a custom domain shows up in them the moment it's verified. Want full control? Ship your own: a public/robots.txt or public/sitemap.xml in your site always wins over the generated file.

Your own 404 page

Add a page at pages/404.blade.php and it becomes your site's not-found page: any URL that doesn't match a page serves your design — with a proper 404 status, so search engines treat it correctly. Style it like any other page: layouts, sections, and components all work. No 404.blade.php? Visitors get a plain not-found response instead.

Export as a ZIP

Your site is yours. Menu → Export → Download ZIP hands you plain static files, compiled and ready to host anywhere — Netlify, GitHub Pages, an S3 bucket, or any web server:

  • Every page is built out to clean URLs (about.blade.php becomes about/index.html, so /about just works).
  • Your public/ files sit at the root, and your CSS is inlined into every page — no build step, no dependencies.
  • Layouts, components, and collections are all baked into the pages — the export is the finished HTML and needs no special server.

The ZIP is the rendered site, not your source. Your editable layouts, components, and collections always live in the builder.

The pre-publish checklist

  • Click through every page in the preview — including at phone width.
  • Check the title and description on your <x-layouts.main> tags (browser tabs and search results use them).
  • Replace any leftover template copy and placeholder links (href="#").
  • Spell-check the headline. It's always the headline.
© 2026 DevDojo Edit this page