How the URL-to-site rebuilder works

The clone-and-rebuild flow is the part of Actium Studio that gets the most attention in demos. Here is what actually happens between the moment a URL is pasted and the moment a redesigned site appears in a staging tier.

Stage one: crawl. An API endpoint accepts the URL, validates it (no private hosts, no localhost, no internal AWS metadata IPs), and dispatches a crawl job onto a Cloudflare Queue. A worker pulls the job, fetches the page tree up to a configurable depth, and stores the raw HTML, headers, and discovered assets in object storage. Each page is hashed; identical pages get deduplicated. The crawler respects robots.txt and rate-limits itself.

Stage two: classify. Once the crawl is complete, an AI worker running on Cloud Run reads the corpus and produces a niche classification: industry, target audience, primary calls-to-action, content categories, and a suggested page taxonomy. The classifier returns a structured JSON payload, not free-form text. Confidence scores travel with every prediction so downstream stages can decide what to trust.

Stage three: theme generation. With the classification in hand, the platform picks a theme template and parameterizes it — color palette, type scale, spacing tokens, primary CTA copy. Colors come from a constrained palette generator that guarantees WCAG AA contrast for body text and AAA for headings. The output is a set of design tokens that the page builder consumes directly.

Stage four: rebuild. The AI worker walks each crawled page, maps its content into the new theme's components, generates SEO metadata (title, description, JSON-LD), and writes the result into a staging tier. The staging tier is a real tenant — tenant isolation is enforced by Postgres row-level security, not by application convention — so the rebuilt site can be browsed, edited, and previewed as if it were already live.

The whole pipeline emits structured logs and OpenTelemetry traces. Every stage is idempotent: if a worker dies halfway through, the next worker picks up where it left off without producing duplicates. The total wall-clock time depends on site size, but a typical ten-page marketing site rebuilds in two to four minutes.

When the rebuild finishes, an email goes to the address that submitted the URL. The email contains a one-time claim link. Clicking it creates an account (or signs in to an existing one), attaches the staging tenant, and drops the user into the CMS. From there it is one click to publish to a custom domain. The whole flow is designed so that nothing exists outside the platform — there is no "download a zip and upload it to your host" step.

The system is observable end-to-end. Every job has a status page. Every failure is captured with stack traces and request IDs that match across services. CodeRadar collects unhandled errors. Audit logs record every write. None of this is optional — it is the secure-by-default runtime we wanted to use ourselves.