Let your bot ship site changes safely: preview first, live on your word
By Šarūnas Vaitkus · about a 6-minute read
Your bot can change your website without ever surprising you. Every change goes to a preview copy first, gets an automated code review, and reaches your live site only when you say "go live". Small fixes can go through on their own once the review passes. You send the prompts below, in order, and it asks you before anything big goes live.
Your site's code in a GitHub repo, or willingness to put it there.
Access to your hosting, such as an FTP, SSH or hosting panel login that you type in yourself.
About 15 minutes for setup and your first approval.
How it works
You send a prompt, the bot does the work, and you approve what matters.
Highlighted [brackets] are yours to replace. Copy keeps them in the prompt.
1
Step 1. Map how your site gets built and published (read-only)
Prompt to send
Look at how [your website address] gets built and published. Don't change anything. Find the repo, the branches, any build step, and where the live files sit on my hosting. Tell me which version of the code is live right now and whether it matches the main branch. If you need a sign-in, stop and tell me. Finish with a plain summary of how a change reaches the live site today.
Why you're sending it
You can't make publishing safe until you know the path a change takes, and a read-only look can't break anything.
What you'll get
A short map from code to live site, with any gap between what's live and what's in the repo.
2
Step 2. Set up a preview copy
Prompt to send
Set up a free preview copy of [your website address] that rebuilds every time the dev branch changes, for example on GitHub Pages. Keep it out of search engines and switch analytics off on it. Give me the preview address. Don't touch the live site.
Why you're sending it
A preview is a safe place to look at every change on a real page before your visitors see it.
What you'll get
A preview address that always shows the latest proposed version of your site.
3
Step 3. Make every change a pull request
Prompt to send
From now on, make every change to [your repo] through a pull request, never straight onto the main branch. Each pull request should say in plain words what changed and why, list the pages it affects and include before and after screenshots on desktop and mobile. Merge it into the dev branch so it shows on the preview.
Why you're sending it
A pull request is a proposed change you can read first. Screenshots mean you don't need to read code to judge it.
What you'll get
One pull request per change, with a plain note and pictures, and the change visible on the preview.
4
Step 4. Add an automated review
Prompt to send
Turn on an automated code reviewer for [your repo], such as Codex or a similar review bot. On each pull request, wait for its review, fix every comment that's real, reply to the ones that aren't with a reason, and ask for a fresh review after your fixes. Add automated checks for the things that broke before, for example a page with two analytics tags or a duplicate sitemap entry.
Why you're sending it
A second reviewer catches things the first bot missed, and checks stop old mistakes coming back.
What you'll get
Pull requests that arrive with a clean review and passing checks, or a clear list of what's still open.
5
Step 5. Agree what counts as minor
Prompt to send
Write down a rule for what you can publish without asking me. Minor means typo and copy fixes, broken links, small style fixes and updates to existing pages, with a passing review and checks. Major means new pages or features, design changes, anything touching forms, payments, privacy text or tracking, and anything you're unsure about. Minor can go live on its own. Major waits for me to say go live. Save it as a standing rule and show it to me.
Why you're sending it
You don't want to approve every typo, and you do want to approve anything visitors would notice.
What you'll get
A written rule both of you can point to, so nobody guesses.
6
Step 6. Back up the live site before every publish
Prompt to send
Before any upload to my hosting, download a copy of the live site files into a dated backup folder and keep the last five. Then upload only the files that changed. Never delete files on the host that aren't in the repo; list them for me instead.
Why you're sending it
If a publish goes wrong, a backup made a minute earlier gets you back in one step.
What you'll get
A dated backup before each publish and a list of anything odd on the host.
7
Step 7. Go live with proof
Prompt to send
When I say "go live", merge the approved pull request into main and publish it to [your website address]. Then load every changed page on the live site with a cache-busting address, check each returns a normal page and not an error, take desktop and mobile screenshots, and send me one short note with the live version, the pages checked and the screenshots.
Why you're sending it
"Done" should mean you've seen it working on the real site, not that the upload finished.
What you'll get
One note per publish with the version that's live and proof that the pages load.
8
Step 8. Know how to roll back
Prompt to send
Write a one-page rollback plan for [your website address]: how to put back the last backup, how to revert the pull request, and how to check the site is back. Test it once on the preview, not the live site. If the live site ever breaks after a publish, roll back first and tell me after.
Why you're sending it
The best time to plan an undo is before you need one.
What you'll get
A tested rollback plan and a bot that restores the site first and explains second.
All in one (optional)
Prefer one prompt? Send this instead.
Prompt to send
Make publishing [your website address] safe, in this order: a read-only map of how changes reach the live site, a preview copy that rebuilds from the dev branch, every change as a pull request with screenshots, an automated review with fixes and checks, a written rule for minor and major changes, a backup before each publish, a go-live step with proof, and a tested rollback plan. Pause after each step to show me what you did. Ask me before any major change goes live, before DNS changes, deleting anything, spending money or sending anything outside.
What your bot will always ask you first
Publishing a major change to your live site.
Changing DNS records or your domain settings.
Deleting files on your hosting or branches with unmerged work.
Spending money, for example on a paid hosting plan or review tool.
Sending anything externally.
It bundles its questions, so you're not pinged all day.