In September 2026, I removed the homepage of criver.site from WordPress. I did not abandon WordPress. I kept it as my publishing CMS, but moved the homepage to a static HTML/CSS/JavaScript setup deployed from GitHub to Xserver.
The reason was practical: as I kept building a game and small web apps, I no longer wanted the site entrance, the blog, and the products themselves to depend on the same WordPress layer.
What was going wrong before
When everything lived inside WordPress, changes to themes or plugins could affect the front page. I also had a more basic deployment problem: pushing code to GitHub did not mean the production site had changed. During the period when I uploaded files manually with FileZilla, GitHub could be current while the live server was still running older files.
That sounds obvious in hindsight, but it is an easy trap when you are a solo builder. A few days later, you may not remember which files were uploaded and which version is really live.
The architecture I use now
- Homepage: static HTML, CSS and JavaScript
- Source of truth: GitHub
- Deployment: GitHub Actions to Xserver
- Articles: WordPress
- Games and web apps: independent from WordPress
WordPress is no longer the container for everything. It is the CMS for articles, which is a job it does very well.
The biggest lesson: push is not deploy
When I first started using Git, I mentally treated “pushed to GitHub” as almost the same thing as “updated the website.” They are not the same. GitHub can contain the correct code while production is still serving an old file.
I ran into this while developing ORA Quest. A JavaScript change could be correct locally and in GitHub while the production version remained old. That changed how I think about the workflow: deployment is not finished until I check the real production URL.
Automation does not eliminate failures
Moving to automated deployment did not magically remove problems. I misconfigured an FTPS host and hit an SSL connection failure. On another occasion, old JavaScript stayed visible because of caching.
The advantage of automation is not that nothing fails. It is that failures become easier to locate. Instead of “the site somehow did not update,” I can ask whether the problem is in the connection, transfer, cache, or production verification.
Why separating responsibilities helped
A solo site does not need enterprise architecture. But separating the entrance, the publishing system, and the actual products made the whole project easier to reason about.
The homepage can focus on being a gateway to what I make. That includes the story-driven game ORA Quest and a one-minute memory game called Oboete Iruka?. WordPress can focus on documenting what I built, what broke, and how I fixed it.
What I would tell another solo creator
Using WordPress does not mean every part of your site has to run through WordPress. And moving part of your site to static files does not mean you have to throw WordPress away.
For me, a static homepage, WordPress for articles, independent apps, and one GitHub-to-production deployment path has become a much cleaner foundation. It is still evolving, but now every failure improves the system instead of adding another manual step.
コメント