How to Set Up Your Website So You Can Update It by Texting Cursor

The CMS most marketing sites actually need is not a dashboard. It is a repo, a preview URL, and a way to describe the change in plain English from wherever you are.

In 2026 that loop is real. You text Cursor something like “swap the homepage headline” or “draft a post from these notes”. A cloud agent edits the site, opens a pull request, and your host builds a preview. You look at the diff and the preview, then merge. Production updates itself.

I have already argued that Git plus an agent can replace a traditional CMS, and that Astro is the right default for most marketing sites. This post is the setup: Astro, GitHub, Netlify or Cloudflare Pages, and Cursor creating and merging the PRs.

What “texting Cursor” actually means

There is no Cursor phone number you can SMS. The messages stay inside the app (or Slack), which is how it should be: a spoofable carrier text with a route into the live site would be a terrible idea.

The interface is a text thread, just inside Cursor:

• Cursor for iOS on a paid plan. Pick the repo, type or dictate the update, let the agent run in the cloud while your laptop is shut.
• cursor.com/agents in a browser. On Android, install it as a PWA from Chrome.
• Slack @cursor if the team already lives in Slack. Same agents, same PRs.

You send a short message. The agent works on a cloud VM against your GitHub repo. You get a notification when there is something to review. From the phone you can read the diff, check the preview deploy, and merge.

If someone is selling you “text this Twilio number and your live site changes”, walk away. The whole point of this stack is review before publish.

Why this stack

Each piece has one job.

Layer	Tool	Job
Site	Astro	Static HTML, content as Markdown, JavaScript only where it earns its keep
Source of truth	GitHub	History, branches, pull requests, permissions
Host	Netlify or Cloudflare Pages	Build on git events, preview every PR, ship main to production
Editor	Cursor cloud agents	Turn a message into a branch, a PR, and (if you say so) a merge

That is the opposite of WordPress: no admin login on the public internet, no plugin estate, no database restore when a headline goes wrong. Rollback is git revert. I have written about why static sites fit this work. Cursor is how you talk to the repo when you are not at a desk.

Origin can sit in this picture later if you want Cursor as the forge. For most sites today, GitHub remains the source of truth and Cursor syncs on top of it. Do not wait for Origin to ship this workflow.

The loop

Once the wiring is done, an update looks like this:

1. You send Cursor a message from your phone.
2. The cloud agent clones the repo, branches off main, and edits Markdown or Astro files.
3. It opens a pull request. Netlify or Cloudflare builds a preview URL on that PR.
4. You review the diff and tap the preview. If it is wrong, you send a follow-up in the same thread.
5. You merge from Cursor (or enable auto-merge after checks). The host deploys main.

The agent can also keep the PR green: watch CI, fix a failed check, reply to review comments. That is the difference between “AI that dumped files into main” and a workflow you can trust from a pub.

1. Put the site in Astro, with content in Git

If the site is still a page builder or a PHP theme, this is the real migration. Astro content collections give you schema-checked Markdown for posts and pages. Copy lives next to components. An agent can change a heading or the component that renders it.

A brochure site, portfolio, or blog does not need a React app framework for this. I compared Astro and Next.js for marketing sites if you are still choosing.

Minimum that makes agents useful:

• Posts in something like src/content/blog/, with frontmatter the build validates
• A local npm run build that fails when frontmatter is wrong
• An AGENTS.md (or CURSOR.md) that tells the agent where content lives, what not to touch, and that production is a pull request, not a push to main

Keep the cloud-specific bit explicit. Cloud agents read AGENTS.md. A short section is enough:

## Cursor Cloud specific instructions

This is a static Astro site.

- Content lives in `src/content/blog/` as Markdown with YAML frontmatter.
- Do not edit `dist/` or lockfiles unless the task is a dependency update.
- Verify with `npm run build` before you open a PR.
- Always open a pull request against `main`. Never push to `main`.
- After the PR exists, include the Netlify or Cloudflare preview URL in your summary and wait for me to merge unless I explicitly say to merge.

If you want a starter that already treats the repo as the CMS, Astro × Claude is the template I ship for that model. The Cursor version of the same idea is this post: same Git-native site, different agent surface.

2. GitHub is the CMS database

Create a GitHub repo. Push main. Turn on a few boring settings so a phone merge cannot wreck the site:

• Protect main. Require a pull request. Do not allow force pushes.
• Allow auto-merge in repo settings if you want Cursor’s “Enable auto-merge” control to work after checks pass.
• Restrict who can merge if clients will send prompts but should not publish. They can still start agents; you merge.

Install the Cursor GitHub app from Cursor Integrations. Grant the site repo (selected repositories, not the whole organisation, unless you mean it). Cloud agents need read-write so they can push branches and open PRs.

This is also why the stack beats a hosted “AI website” product. You own the git history. You can change hosts next year. The agent is a contributor, not the landlord.

3. Deploy from Git: Netlify or Cloudflare Pages

Pick one static host and connect the GitHub repo. Both will:

• Deploy main to production
• Build a unique preview URL for every pull request
• Let you roll back a deploy from the dashboard if you need a faster undo than a revert

Build settings for a normal Astro site:

• Build command: npm run build
• Publish directory: dist

You can put that in a netlify.toml on Netlify:

[build]
  command = "npm run build"
  publish = "dist"

On Cloudflare, Workers & Pages → Create → Pages → import the GitHub repo. Choose the Astro preset if it appears, then confirm the same command and dist. Production branch is main.

Which host?

	Netlify	Cloudflare Pages
Preview deploys	Excellent, the default mental model	Excellent, PR preview URLs on every branch
Forms, redirects, identity	Very easy if you already live there	Doable; more “Cloudflare-shaped”
DNS and CDN	Fine	Often already your DNS, so fewer moving parts
Free tier for a brochure site	Enough for light traffic	Generous for static files
Agent-native extras	Agent Runners if you want Netlify to run the agent	Not the point; Cursor runs the agent

For this workflow, the host is the boring half. Cursor is the CMS. I would pick Netlify if the team already uses Deploy Previews and plugins. I would pick Cloudflare Pages if the domain already sits on Cloudflare and you want the edge bill to stay near zero. Either is correct. Vercel works the same way if that is what you already have.

Confirm preview deploys with a dummy PR before you involve a phone. If the preview URL is not showing on GitHub, fix that first. The phone review is worthless without it.

4. Give Cursor a cloud environment that can build the site

A cloud agent that cannot install dependencies or run the Astro build will guess. Environment setup is the part people skip, then blame the model.

In the Cloud Agents dashboard, connect the repo and let Cursor set up the environment, or commit a small .cursor/environment.json:

{
  "install": "npm install",
  "start": "npm run dev -- --host 0.0.0.0 --port 4321"
}

install runs when Cursor prepares a Build, so the next agent starts with node_modules already there. start brings up the dev server so the agent can click through the site in its VM and attach screenshots to the PR.

For a static marketing site you rarely need secrets. If you do (a form backend token, an analytics write key used at build time), put them in the Cloud Agents secrets tab, not in the repo.

5. Make Cursor create pull requests, then let you merge them

This is the setting that turns “agent pushed a branch” into “I can ship from my phone.”

Open Cloud Agents → My Settings and set Create PRs so agents open a pull request when they finish, not only push a cursor/… branch. If PRs stay optional, the iOS app is awkward: you will be staring at a branch with no review card, and auto-merge has nothing to attach to. If a run ever stops on a branch, send a follow-up: “please open the PR.”

On GitHub:

• Enable Allow auto-merge if you want Cursor to queue the merge after checks
• Keep branch protection on main so auto-merge still means “checks passed”, not “the model felt confident”

From Cursor for iOS you can then squash-merge, mark ready, update the branch, toggle auto-merge, or close. That is the publish button.

Two policies I actually use:

• Copy and typos: agent opens PR, I glance at the preview, merge from the phone.
• Layout, nav, pricing, anything legal: agent opens PR and does not merge. I look at the preview on a real screen. Follow-ups in the same thread if needed.

You can say that in the prompt every time, or put it in AGENTS.md so you do not have to.

6. Put the app on your phone

Download Cursor for iOS, sign in with the same account, pick the site repo.

On Android, use cursor.com/agents and install the PWA.

First test, from the sofa:

In the marketing site repo, add a hidden /health-check heading on a draft blog post titled “Agent pipeline test”. Open a pull request. Do not merge. Paste the preview URL when the host finishes building.

If that PR appears, the preview loads, and merge is a tap you choose not to hit, the stack works. Delete the test post in a second PR, or tell Cursor to close it.

Optional: install the Slack integration and treat #website as the inbox. @cursor update the footer address to … is the team version of texting.

What to text (and what not to)

Good messages are specific and include the publish rule:

• “Change the homepage H1 to ‘Websites that stay fast’. Do not touch the rest of the hero. Open a PR, do not merge.”
• “Fix the typo on /services/web-development/. PR and merge after the preview looks right.”
• “Write a blog post from these notes: … Use tags Web development, Astro. Follow the existing frontmatter. Open a PR, do not merge.”
• “The contact page still lists the old phone number. Replace it everywhere it appears. PR only.”

Bad messages are how you get a surprise redesign:

• “Make the site pop”
• “Update the website” with no URL, no copy, no constraint
• “Push this straight to production”

If the change needs a photo, attach it in the iOS app and say where it goes. Cursor can use images as visual direction. Still review the preview. Compression, crop, and alt text are where agents get casual.

What this costs, roughly

Pricing moves, so check the vendor pages. The shape is:

• GitHub: free for a private repo at this scale
• Netlify or Cloudflare Pages: free tiers cover a typical brochure site; you pay if you leave the free quotas
• Cursor: cloud agents are on paid plans (Pro and up). Usage is API-priced for the model you pick, with a spend limit you set

Compare that with managed WordPress hosting plus premium plugins plus the hours you spend updating them. You are paying for an agent subscription and a static host, not for a CMS product.

Guardrails that make this safe

• Never let the agent push main. PRs only.
• Preview is the review. If you cannot open the preview on the phone, do not merge layout work.
• Branch protection stays on even when you trust the agent. Trust is not a security control.
• One site, one repo, selected GitHub app access. Do not give Cursor every private repo “for convenience”.
• Secrets stay in Cursor or the host, not in Markdown.
• Humans still own taste. Agents are fast at copy, files, and wiring. They are average at brand. That is why you look at the preview.

This is still managed hosting as a product if you run it for a client: DNS, SSL, who is allowed to merge, what happens when a build fails on a Saturday. The text thread does not remove that layer. It removes the fake need for wp-admin.

When this is the wrong CMS

Skip it if you need a dozen non-technical editors, localisation workflows, scheduled embargoes across five brands, or a content API feeding an app. That is still a real CMS.

For a twelve-page marketing site, a blog, and the kind of updates that used to mean logging into WordPress from a phone: Astro + GitHub + Netlify or Cloudflare Pages + Cursor is enough. The repo is the CMS. The PR is the draft. The preview is the staging site. The merge is publish.

If you want that stack built and handed over so the first text you send is a real update, not a plumbing ticket, get in touch.