WordPress theme customisation is modifying an existing WordPress theme — Astra, GeneratePress, Kadence, Divi, Avada, OceanWP, or any theme — to match your brand and requirements, without rebuilding the whole site from scratch. I implement all changes via a WordPress child theme, so your customisations survive parent theme updates. Work covers CSS and PHP overrides for brand colours, typography and spacing; custom template parts for sections the theme doesn't cover; layout restructuring; and cleanup of conflicts or abandoned customisations from previous developers. Priced and delivered on a fixed-scope basis.
Who it's for
What's included
How the process works
Audit the theme
I review what the parent theme supports natively vs what needs custom PHP or CSS, document all existing customisations (including leftover code from previous developers), and flag any conflicts before writing a single line of new code.
Build on staging
All changes go through a child theme on a staging copy of your site — never directly editing the parent theme or live files, so your live site is untouched throughout.
Review & revise
You review the staging URL with your real content and brand assets. I adjust until the result matches your brief in a single revision round.
Deploy with rollback
Changes pushed live via the child theme with a rollback point via Git. The parent theme can still be updated independently without touching your customisations.
Common questions
Yes — all customisations are implemented in a WordPress child theme, which is a separate plugin-like theme that inherits from the parent but keeps your overrides independent. When the parent theme (Astra, GeneratePress, Kadence, Divi, Avada) releases an update, WordPress applies it to the parent theme files only — your child theme's CSS overrides, template part overrides and custom functions remain untouched. This is the WordPress-standard method for safe, update-proof theme customisation. I also commit all child theme code to a Git repository so every change is version-controlled and can be rolled back.
Yes — this is a very common request. Previous developers sometimes add conflicting customisations in multiple places: the WordPress Customizer, a child theme's functions.php, inline styles via the Additional CSS field, and a page builder's per-element CSS — all targeting the same element with different values. I audit every location where customisation code exists, document what each piece does, remove redundant or conflicting overrides, and consolidate everything into a clean child theme with CSS custom properties. The result is a site that looks correct and has a single, maintainable set of customisations you can hand to any future developer without embarrassment.
Yes. I add custom template parts (PHP template files in the child theme directory) for sections the parent theme doesn't include — custom hero layouts, testimonial sections, feature comparison tables, pricing grid sections, team roster templates. These template parts are called from custom page templates or via WordPress template hierarchy overrides in the child theme, so they integrate with the existing theme's CSS and JavaScript without duplicating the parent theme's full layout structure. For more complex new features that need WordPress admin UI or custom post types, see custom plugin development — those are better implemented as standalone plugins rather than theme template files.
I'll tell you clearly during the audit phase if a customisation project would be forcing something onto an incompatible theme — and what a realistic alternative looks like. Some themes (particularly older premium themes like Avada pre-v7, or heavily customised Divi installs) have architectural constraints that make certain layout changes practically impossible without rebuilding core theme templates in ways that break on updates. In those cases, a targeted rebuild of the affected templates as a headless theme layer, or a full migration to a lighter theme like Astra or GeneratePress, may be a more cost-effective solution than fighting the constraints. Custom theme development from scratch removes all those constraints — I'll give you an honest comparison of costs and timelines for both paths.
Often, yes. Many Core Web Vitals problems (CLS from images without explicit width and height attributes, LCP caused by a large hero image loaded without preload link, INP from event listener overhead in the theme's JavaScript) are fixable at the theme level without plugin-level caching changes. During a theme customisation project, I audit Core Web Vitals alongside the visual changes and fix any performance issues within theme scope. For deeper performance work — Redis object cache, database query optimisation, server-side caching — that goes beyond theme scope and into dedicated speed optimisation work.