Getting started

Eight short sections: signing in, making a site, editing it, trying a change without committing to it, working alongside other people, seeing it before anybody else does, publishing it, and pointing an AI assistant at it. Read the one you need.

Every project here is a real Git repository and a plain Astro site. Nothing below locks you in: Export on any project page gives you the whole thing, history included.

1 · Sign in

There is no password to forget. Type your email address on the sign-in page and you get a link and a six-digit code — either one signs you in, so the code works when the link opens in the wrong browser.

Add a passkey from Account once you are in. It signs you in in one gesture, and it is what confirms the actions that ask “are you really you” — deleting a project, closing an account, minting a long-lived token.
Invited to somebody else’s account? The invitation link signs you in and joins you in one step. Their projects are on your projects page afterwards.

2 · Create a site

On Projects, fill in What is the project called?, pick the Account it belongs to and a Starting point — one of eight templates. A real Git repository is created and seeded; it takes a few seconds, and the project says Setting up until it is ready.

Already have a website? Put its address in the import field instead. The importer reads WordPress, Drupal, a sitemap or the pages themselves, and lands the result as a draft for you to review — never straight onto a live site.
Already have a repository? Choose the empty starting point and push to the Git URL on the project page. The first push finishes the setup.

3 · Edit an existing site

You never edit the live site directly. You edit a draft, and a draft is a branch: everything in it is invisible to visitors until you publish.

Open the project and press Start a new set of changes, or open one that is already under Open drafts.
Press Open the editor. If your role is read-only the same button says View in the editor and the editor opens without its controls.
Every save is a commit, by your name, with a history you can read — and an identical save makes no commit at all.

4 · The visual editor

A page is a tree of blocks. The left column lists your pages and the blocks on the page you are editing; the middle is the page itself; the right is the settings for whatever you have selected.

Canvas and On page are the two ways to edit. Canvas is the editable structure; On page is your real site with the text editable where it sits. The toolbar switches between them.
Saving is automatic — the toolbar says Unsaved, Saving…, then Saved ✓. Undo and redo work the way you expect.
Media in the sidebar is the site’s image library: drop a file in, give it alt text, use it anywhere. Uploaded images are resized and re-encoded when the site is built.
Settings holds the things that belong to the whole site — menus, the design tokens (colours, type), redirects, and whether a page is hidden from search engines.
You cannot invent structure. A block type has fields, and a save that does not fit the project’s schema is refused with the exact field named. That is deliberate: it is what keeps a site somebody else built from breaking under you.

5 · Trying something, and working with other people

A fork is a second line of content inside a draft — a place to rewrite the homepage for a campaign without holding up everything else in the draft.

The Which content you are editing control at the top of the editor says Main draft. Switch it to start a fork; give it a name (What to call this fork) and edit as normal.
A fork previews on its own, so you can send somebody the campaign version and the ordinary draft separately.
Merge, keeping the versions you chose folds it back in. If the same document changed on both sides you are asked about each one — Keep the draft’s or Keep the fork’s — and nothing merges until you have answered. Delete the fork throws it away.

Two people can edit the same page at the same time and both sets of edits survive. You see who else is in the document and where they are; undo takes back your change, not theirs.

On a document nobody else is in, the older protection still applies: if somebody changed it since you opened it, your save is refused rather than silently overwriting them. Reload and re-apply.
Roles decide what each person can do: a reviewer reads, an editor edits but cannot publish, an admin publishes. Invite people from the account’s People page, or give somebody access to one project only from that project’s Settings.

6 · Seeing it before anyone else

Two different things, and it is worth knowing which one you want.

The live preview, inside the editor. Open preview in the toolbar puts your real site beside the editor and refreshes it as you save. It is for you, while you work.
A draft preview, for other people. Build a preview on the draft page builds the whole site and gives you a link on an unguessable address. It takes a moment; the page tells you when it is ready and the link stays until the next one. That is the link you send to a client.
Need it tighter than unguessable? Settings → preview access lets you put a passphrase on it, after which nothing on that address is served without it — pages, images and the still-building screen alike.

7 · Publish

Publish on the draft merges it into the live branch, builds the site and deploys it. The project page shows it moving through Building to Live.

If your project asks for review, an editor submits and an admin approves; the Discussion on the draft is where that conversation happens.
Changed your mind? Rollback under Published history puts the previous build back — it redeploys the artifact that was already there rather than rebuilding, so it is fast — and opens a draft that undoes the change, so you are not left to fix it forward.
Where it publishes is on the project page: our hosting by default, or Cloudflare, Netlify, GitHub Pages and the rest into your own account — or a ZIP you can unzip anywhere. Connect a domain you own is on the same page.
A publish can never move a site backwards: an out-of-order deployment is recorded as superseded rather than applied.

8 · Use an AI assistant

Claude Code — or anything that speaks MCP — can work in a draft through exactly the same API and the same validation the editor uses. It sees what you see, it is refused what you would be refused, and every change it makes is a commit with your name on it.

The one-minute version

Open the draft, press Connect Claude Code, and run the line it prints. It looks like this:

claude mcp add --transport http webentor \
  "https://edit.<your-domain>/mcp?draft=<draft-id>" \
  --header "Authorization: Bearer wct_…"

That token opens that project’s content, media and previews for 24 hours, and nothing else. It is shown once — we store only a hash of it — and you can revoke it from Account at any time.

Then just ask

“What blocks can this site use?” · “Rewrite the pricing page for a smaller audience, on a fork, so I can compare” · “Find every page that still says our old address and fix it”. Claude Code also picks up ready-made prompts as slash commands — /new_page, /edit_page, /try_on_a_fork, /review_draft, /find_and_replace and five more.

Wider, or narrower

Account → Assistant tokens mints one for a whole project, with only the doors you tick — content, media, previews, publishing — and a lifetime you choose. Anything beyond the one-minute shape asks you to confirm who you are first.

There is a second door for running the account rather than one site — creating projects, building, deploying, attaching domains — at https://api.studio.webikon.eu/mcp, with a token carrying the projects or deploy grants.

An assistant can never do more than you can. Its token carries your role, narrowed to the grants you gave it. An editor’s assistant cannot publish however it was minted; an admin’s cannot publish unless you ticked publishing. A refusal comes back as a sentence saying which of the two it was.

When something is wrong

A build failed. The reason is on the draft or project page beside the build — it is the site’s own build error, and it is usually a page referring to something that is not there. Fix it and try again; a failed build never touches the live site.
A save was refused. Either somebody else changed the document (reload and re-apply) or the content does not fit the schema (the message names the field).
You are stuck. Everything you have is exportable and clonable at any moment — Take it with you on the project page — so nothing here can hold your work hostage while you work out what happened.