Before building anything, it helps to know that a WordPress site is really two things, kept in two different places. Once that clicked for me, continuous deployment made sense.
In short:
- The code (the theme) lives in Git and GitHub. The content (posts, pages, images) lives in the database.
- Code only moves from my laptop to the live site. Content stays on the live site.
- Continuous deployment means every push to
mainis sent live automatically, with no files copied by hand.
What is a WordPress site made of?
- The code. This is the theme: the templates, the styles, the design system. It’s a folder of files.
- The database. Every page, post, menu, image and setting you type into the WordPress dashboard. It lives in a database (MySQL), separate from the code.
WordPress reads both to build a page. The code says how things look, and the database says what’s on the page. Delete the code and your content survives, just without its design. Delete the database and you have a nicely styled empty shell.
Why they travel differently
The code only changes when I decide to change it, so I want a history of it: what changed, when and why, with a way back if something breaks.
The content changes all the time, on the live site, by anyone with a login. It needs backups, but it can’t follow the same path as the code.
Git and GitHub, briefly
- Git keeps save points for a folder. Each save point (a commit) is a snapshot with a short note on what changed. I can look back at any of them or go back to one.
- GitHub is an online home for that history. It’s a backup, and it’s where my deploy starts.
- Pushing means sending my new commits from my laptop up to GitHub.
The main version of the code is called main. On my site, whatever is on main is what’s live.
What is continuous deployment?
Every time I push a change to main, GitHub kicks off a job that builds the theme and copies it to the live server. I don’t drag files across, and I can’t forget one. (Right now I start the machine that runs that job by hand, for a security reason covered in part 4.)
Without it, updating a site means opening an FTP app (a program for copying files to a server) and uploading the changed files by hand, hoping you’ve picked the right ones. Now the history is in GitHub, and the live site matches the last push.
You’ll often see continuous deployment paired with continuous integration, as CI/CD. Continuous integration means every change is checked automatically before it’s merged. It earns its keep when lots of people work on the same code. On a site I build on my own, I skipped it.
Two one-way streets
- Code goes one way: my laptop, then GitHub, then the live server. I never edit code directly on the server, or GitHub stops being the true version.
- Content stays on the live site. I never build pages on my laptop and push them up, or I’d overwrite real content.
When I want to test new code against real content, I copy the live database down to my laptop. Never the other way: pushing a local database up would replace real posts with my test junk.
Mixing these two up is an easy way to end up with a site nobody trusts.
The catch
WordPress lets you change more than content in the dashboard. Its Site Editor lets you change templates, headers and styles by clicking, which is lovely, but those edits are saved to the database, not to the code. They skip Git entirely, and they quietly win over the files. Part 6 is all about that.
Where Claude Code fits
Claude Code works in the theme folder on my laptop. It writes the templates and styles, makes commits, and pushes when I ask it to.
That last part matters, because a push is a deploy. The rules file in my theme folder, which Claude reads at the start of every session, says to commit only when I ask and never push without asking. That one rule is my safety net.
Next in the series: picking a host, and running a copy of the site on my laptop.
