A smaller codebase can give you more direct control
The original article came from practical frustration with plugin maintenance and a desire for a simpler stack. That remains a valid reason to move when the website does not need a full CMS.
- Fewer dependencies: ship only the components the site actually uses.
- Direct performance control: reduce unnecessary database calls, scripts and styles.
- Design freedom: build reusable components without working around a theme.
- Deployment ownership: use Git, staging and a release process suited to your site.
- Transparent architecture: developers can see exactly where headers, footers, navigation and page logic live.
WordPress vs plain HTML/PHP
Neither approach wins every category
| Area | WordPress | Custom HTML/CSS/JS/PHP |
|---|---|---|
| Content editing | Strong browser-based editor and publishing workflow | Requires code editing or a custom/headless CMS layer |
| Setup speed | Fast when a theme/plugin ecosystem matches the requirement | Slower initially because components must be built |
| Performance | Can be excellent with careful architecture and caching | Can be very lean because only required code is shipped |
| Security | Requires disciplined updates of core, plugins, themes and accounts | Smaller surface is possible, but security becomes your responsibility |
| Customization | Broad ecosystem; complex custom work may fight theme/plugin assumptions | Full control over markup, routing and application logic |
| Editorial team | Excellent for non-technical contributors | Needs an editing workflow if contributors should not touch code |
AI lowers the barrier to small code changes—but it does not remove engineering responsibility
AI tools can help scaffold components, explain code, generate CSS variations and speed up repetitive development. That makes small custom sites easier to maintain for technically capable owners.
Generated code still needs review for security, accessibility, browser behavior and compatibility with the rest of the application. AI assistance is not a substitute for backups, testing, version control or understanding what will run on the server.
If you move away from WordPress, preserve the URLs and useful content
- Inventory the current URLs, traffic, backlinks and conversions.
- Identify the pages and media that must be preserved.
- Create reusable header, footer, navigation and content components.
- Keep existing URLs where practical.
- For changed URLs, map one-to-one 301 redirects to the closest replacement.
- Update internal links so the new site does not rely unnecessarily on redirects.
- Update canonical tags and XML sitemaps.
- Test forms, analytics, Search Console, structured data and mobile rendering.
- Monitor crawl and search performance after launch.
This is the same preservation-first principle we use in the Plus2Net modernization project: do not remove useful material merely because the template changes.
A simple PHP include structure can remove a lot of duplication
<?php require __DIR__ . '/templates/head.php'; ?>
<?php require __DIR__ . '/templates/header.php'; ?>
<main class="container">
... page content ...
</main>
<?php require __DIR__ . '/templates/footer.php'; ?>The exact structure can be more sophisticated, but the basic benefit is that shared layout code is edited once rather than copied into every page.
Custom code is not secure automatically
- Validate inputs on the server.
- Escape output to reduce XSS risk.
- Use prepared database statements.
- Add CSRF protection where appropriate.
- Protect secrets and configuration from public access.
- Keep PHP and libraries updated.
- Use restricted file permissions.
- Maintain tested backups and logs.
Do not rebuild a CMS simply because custom code feels cleaner
WordPress can remain the better fit when:
- Many non-technical people publish or edit content.
- The site depends on mature editorial workflows, roles and scheduling.
- A well-supported plugin solves a complex requirement economically.
- The team already has strong WordPress maintenance expertise.
- Speed to launch matters more than owning every line of the stack.
The choice does not have to be all-or-nothing
A site can use static or PHP-rendered pages for stable sections while using a CMS only where editors need it. Headless CMS platforms, static-site generators and API-driven content are other options.
Choose the architecture you can maintain well
A lean custom stack can be excellent for a site with technical ownership and stable content patterns. WordPress is excellent when editorial convenience and ecosystem speed matter. Security and performance depend much more on implementation discipline than on the platform name alone.
