WordPress Website Development: What Businesses Actually Need

Most WordPress advice is written either for developers or by hosting companies. This is written for the person paying the invoice.

The thing worth understanding up front: a WordPress project is not mainly a design exercise. Design is the visible part, and it is the part everyone argues about, but the decisions that determine whether the site is still working well in three years are structural. They get made in the first week and they are expensive to reverse.

What you are actually buying

A WordPress website is four things bolted together, and they fail independently.

The content model. How your pages, services, case studies, locations or products are structured in the database. This is the single most consequential decision in the project and almost nobody asks about it. If your ten service pages are ten hand-built pages, adding an eleventh means rebuilding a page. If they are a content type with defined fields, adding an eleventh takes ten minutes and it inherits the layout, the schema markup and the internal linking automatically.

The theme. The templates that turn that content into HTML. Custom-built, a commercial theme, or a page builder — this is the decision covered in WordPress design versus development, and it has more to do with who will edit the site than with how it looks.

The plugin stack. Every plugin is a dependency you are agreeing to maintain, forever. More on this below, because it is where most slow, fragile WordPress sites come from.

The hosting. Where it runs, how it is backed up, and who has the credentials. Your name should be on this account. If your developer owns the hosting, you do not own your website in any practical sense.

The content model comes first

Before any design work, someone should be able to answer: what types of content does this site have, and what fields does each one need?

For a typical service business that is something like:

The test is simple: if you will have more than about three of something, it is a content type, not a page.

Custom theme, commercial theme, or page builder

There is no universally correct answer. There is a correct answer for your situation, and it depends almost entirely on who edits the site after launch.

The honest summary: page builders buy editing convenience with page weight and a permanent dependency. Custom themes cost more up front and less thereafter. Commercial themes are a reasonable middle ground if you accept the constraints, and a trap if you fight them with fifteen plugins.

What matters more than the choice itself is that it is made deliberately, for a stated reason, and that you are told what the trade-off is.

Plugins: the part that goes wrong

Most slow, unstable WordPress sites got that way one reasonable decision at a time. Each plugin solved a real problem on the day it was installed. Nobody ever removed one.

Every plugin adds:

• code that runs on page load, often on every page whether it is needed or not
• a dependency that must be kept updated, or becomes a security hole
• a potential conflict with the next plugin
• a chance the vendor abandons it

A practical rule: every plugin should be justifiable in one sentence, and that sentence should be written down somewhere you can find it in two years. When a build is handed over, ask for the list and the reasoning. If nobody can explain why something is installed, that is the first thing to test removing.

The plugins that genuinely earn their place on most business sites are few: a caching layer, a backup tool, a security layer, an SEO plugin, a forms plugin, and whatever handles your specific business requirement. Anything beyond that should have to argue for itself.

Where SEO fits into a build

SEO added after launch is remedial work. Some of it — content, links, ongoing optimisation — is genuinely ongoing. But the structural parts are far cheaper to do during the build:

• URL structure that will not need changing later
• a heading hierarchy that reflects the actual content
• internal linking designed into the templates, not added by hand
• structured data generated from the content model rather than hand-written per page
• images sized and formatted properly from the start
• a sitemap that reflects what is actually on the site

This is covered properly in what makes a WordPress website SEO friendly, and it is the reason the SEO service and the WordPress development service overlap as much as they do.

Performance is a build decision, not a plugin

You can improve a slow WordPress site with caching. You cannot cache your way out of a heavy one. The weight is set by the theme, the builder, the plugin stack and the images — all decided during the build.

The targets worth holding a build to, measured on a mid-range Android over a throttled connection rather than on a developer's laptop:

• Largest Contentful Paint under 2.5 seconds
• Interaction to Next Paint under 200 milliseconds
• Cumulative Layout Shift under 0.1

If those terms are unfamiliar, Core Web Vitals explained covers what each one actually measures and why it matters to a business rather than to a developer.

What a sensible project looks like

1. Discovery. What the site needs to do, who it is for, what content exists, what has to be preserved from the old site. Output: a scope and a fixed price.
2. Content model and structure. Content types, fields, URL structure, navigation. Output: a sitemap and a set of templates to build.
3. Design. Applied to real content, not lorem ipsum. Designing against fake content is how you end up with a layout that breaks the moment a real service description is longer than the placeholder.
4. Build. Templates, content model, functionality, plugin stack.
5. Content migration and QA. Cross-browser, mobile, forms tested end to end, redirects mapped if URLs are changing.
6. Launch and handover. DNS, SSL, analytics, Search Console, a walkthrough of how to edit it, and the credentials in your name.

If a proposal skips step two, ask why.

Questions worth asking before you sign

• Who owns the hosting account and the domain? *(Correct answer: you.)*
• Which parts of the site can I edit without a developer?
• What is the plugin list and why is each one there?
• What happens to my existing URLs?
• What performance target are you building to, and how is it measured?
• What does support look like after launch, and what does it cost?
• If I stop working with you, what do I have?

The last one is the most revealing. A developer building things properly will have a straightforward answer.

Where to go next

If you are trying to work out budget, what a WordPress website costs in the UK breaks down what actually drives the number. If you have an existing site and are not sure whether to fix or rebuild, when to rebuild your site walks through that decision. And if you are trying to assess a developer, how to choose a WordPress developer covers what to ask.