Site setups

Different sites ship differently.Start with who publishes live.

WordPress, Shopify, GitHub, Webflow, HubSpot, Contentful, Sanity, Payload, and Wix can take a live write path where their API allows. Framer, Squarespace, and custom CMS stay a publish brief. The first question is still: who can put the finished page on the production site?

Page last updated .

Who publishes

Three ways a page gets live

Pick the path that matches production access today. Measurement and scoring still work if a human has to press publish.

  • Agent ships or proposes

    Best when production access is clear: a write-capable CMS connection, or a review-gated PR path on GitHub.

  • Team publishes to production

    Works on every platform. AEOForged can still score, draft, verify, and measure while your team handles the final publish step.

  • Repo-first handoff

    On a code site, ship through a pull request. Branch previews keep the change reviewable. A shared staging URL is not the source of truth.

  • WordPressApplies fixes
  • ShopifyApplies fixes
  • GitHubApplies fixes
  • WebflowApplies fixes
  • WixApplies fixes
  • SquarespacePublish brief
  • FramerPublish brief
  • HubSpot CMSApplies fixes
  • ContentfulApplies fixes
  • SanityApplies fixes
  • PayloadApplies fixes
  • Custom CMSPublish brief

Already editing with an agent?

We plug into that setup

We research and score. Your agent writes and applies in the files you already have. We measure the live page.

  • Stay in the editor

    Cursor, Claude Code, or whatever already has the site files. If the repo is open, you do not need to connect GitHub through AEOForged. A CMS connection is optional apply-fix — not a requirement to start.

  • Keep your publish path

    The agent bootstraps, takes the next task, and ships the way you already ship: a pull request, a write-capable CMS, or a human publish step. We do not replace your deploy.

  • The live URL is the finish line

    We research and score. Your agent writes. Nothing counts as done until verify-page re-checks the production page — not a preview, not a staging URL.

Quick chooser

Who ships the finished page?

Pick the live-site publisher first. That one answer tells you whether AEOForged should connect directly, open a PR, or stay in propose-only mode.

Who can put a finished page on your live production site (not staging)?

What best describes how the site is built?

Pick one option above to see the recommended working mode, any warning flags, and how each package behaves on that setup.

Common setups

The usual site shapes

These are the default working modes behind the chooser. Pick the setup that looks closest to yours and use it to decide whether the right next move is a connector, a PR flow, or a human publish path.

  • WordPress

    AEOForged can connect via WordPress Application Password (Applies fixes). Your agent drafts and scores in AEOForged; with ship permission it can apply through the connection. Prefer a personal or staging preview when your team shares one sticky preview URL.

  • Shopify

    Connect with a store API token (Applies fixes). Same pattern: measure and score in AEOForged; live apply only when you grant ship permission.

  • Code site on GitHub

    Best agent path: GitHub pull requests (review-gated, Applies fixes). Each PR can have its own preview so people stop fighting one shared staging site.

  • Code site, not on GitHub

    Point work access at the git repo and deploy notes. AEOForged does not open GitLab/Bitbucket PRs today — your agent or team deploys, then we measure the live URL.

  • Builders (Webflow, Wix, Squarespace, Framer, …)

    Webflow (Applies fixes), Wix (Applies fixes), Squarespace (Publish brief), Framer (Publish brief), HubSpot CMS (Applies fixes). Webflow, HubSpot, and Wix can connect for the fields their APIs allow; Framer and Squarespace stay a publish brief. Retainers still work: agent writes and scores here; your team publishes in the builder when we cannot apply; you give us the live production URL for social packs and measurement.

  • Headless / enterprise / custom CMS

    Contentful (Applies fixes), Sanity (Applies fixes), Payload (Applies fixes), Custom CMS (Publish brief). Contentful, Sanity, and Payload can connect and apply on existing entries. Custom CMS stays brief-only. Treat like a builder unless you also have a git repo we can use. Custom CMS is not the same as a Rebuild package — Rebuild is a quoted replatform onto connectable infrastructure, and maintenance after handoff is named separately.

  • Shared staging / one preview

    If everyone shares one staging URL, collisions are normal. Prefer per-change previews (PRs). Never use a staging URL as the Grow/Dominate delivered article URL — production only.

  • AI crawlers can’t read the site

    Measurement retainers can still watch answer engines. On-site fixes need Fix Programme (you/agent apply) or a quoted Foundation / Rebuild path — Grow does not unblock a blocked crawl by itself.

Honesty

What a connection actually does

  • If the site files are already in your editor, you do not need to connect GitHub through AEOForged.
  • Live write connectors today include WordPress, Shopify, GitHub, Webflow, HubSpot, Contentful, Sanity, Payload, and Wix. Some page bodies stay a publish brief (Webflow static pages, HubSpot website modules, Wix Editor).
  • Framer, Squarespace, and custom CMS get a Publish brief. We name the CMS; that is not a live write path.
  • Retainers do not require a connection. They can run as measured drafts, content picks, social packs, and live verification against the production URL.
  • Foundation and Rebuild are quoted we-apply or replatform paths, not instant self-serve connectors.

Next step

Choose the path that fits how your site really ships

Hand the setup to your agent, compare package paths, or join the waiting list while signup is closed.