WordPress

A custom theme should be a small, intentional codebase: templates for the content types the site actually has, reusable template parts instead of copied markup, responsive layouts built on semantic HTML, and only the scripts and styles each page needs.

Heavy multipurpose themes trade a fast start for years of unused code, conflicting settings and slower pages.

Business functionality — booking rules, integrations, custom workflows — belongs in a plugin, not in the theme's functions.php, so it survives a redesign. Plugins hook into WordPress through actions and filters instead of modifying core or other plugins, keep their logic in classes with a clear structure, and register their admin screens, settings and capabilities explicitly.

Much of the maintenance pain on WordPress sites comes from content modelled as formatted pages. Custom post types for distinct things (rooms, events, team members), taxonomies for how they're grouped and filtered, and custom fields for structured attributes let templates render consistently — and let editors change content without breaking layouts.

External APIs — booking engines, CRMs, email platforms — are called from server-side code with timeouts and error handling, credentials kept out of the database where possible, and responses cached with transients so a slow third party doesn't slow down every page view. When an integration fails, the page degrades gracefully instead of breaking.

Payment flows are where WordPress code needs the most discipline. The payment provider confirms payment through a verified callback or webhook — never through a redirect URL the customer's browser could fake. Amounts are calculated on the server, orders move through explicit states, and callbacks are idempotent because providers retry them.

A large share of WordPress accessibility problems comes from themes and plugins rather than content: missing landmarks, inaccessible menus and sliders, forms without labels, plugin output that injects unlabelled buttons.

Accessible WordPress means semantic templates, keyboard-operable navigation with visible focus, form plugins configured with proper labels and errors, checking what each plugin actually outputs against WCAG — and giving editors the structure (headings, alternative-text fields) to keep content accessible after launch.

Slow WordPress sites are usually slow for the same reasons: plugins loading scripts on every page, unoptimised images, uncached pages and heavy database queries inside templates. The fixes follow directly — remove what isn't needed, load assets only where they're used, serve responsive compressed images, cache pages and objects, and watch for queries inside loops.

Most WordPress compromises go through outdated plugins and themes, weak credentials or excessive permissions. Core, themes and plugins are kept updated; abandoned plugins are replaced; users get the lowest role that works.

Custom code follows WordPress's own rules: capability checks and nonces on every action, sanitize input on save, escape output on render, and prepared statements for custom queries.

Clients live in the admin, so it's part of the product. Custom fields with clear labels and help text, editor blocks restricted to what the design supports, simplified menus for editors, and admin pages for business settings turn WordPress into a tool clients can use confidently without breaking the site.

The REST API lets WordPress serve content to other applications — a mobile app, a JavaScript frontend, another system. Custom endpoints get proper permission callbacks and validated arguments, and it's worth checking what default endpoints expose: data that should be private leaking through them is a common oversight.

Headless WordPress — WordPress for editing, a separate frontend for rendering — makes sense when the frontend needs to be an application, when content feeds several channels, or when performance and tooling requirements outgrow themes.

It also adds a second application to build, host and secure, breaks previews and many plugins, and moves responsibility for SEO and accessibility to the frontend. For a content-led business site, a well-built traditional theme is usually the better trade-off.

A WordPress site is never finished: updates tested on staging before production, automated off-site backups that have actually been restored at least once, compatibility checks before major PHP or core upgrades, and uptime and error monitoring. A maintenance routine is what keeps a site secure two years after launch.