WordPress Website Design: What the Process Really Takes

WordPress powers over 40 percent of the web. That statistic gets quoted constantly. What almost nobody talks about is how poorly most people understand what actually happens between a signed contract and a working URL. The gap produces predictable damage: missed expectations, bloated scope, and sites that look polished in Figma but buckle the moment real users show up. This is a stage-by-stage account of the real work, written so you can evaluate a proposal with actual judgment and hold whoever builds your site to a concrete standard.

The work that happens before anyone opens Figma

Most teams get this wrong. They treat discovery as a formality, a few kick-off calls before the “real” work begins. It isn’t. The choices made in the first two weeks determine whether the rest of the project has any chance of succeeding.

Discovery is where you establish what the site must do, who it serves, and what limitations you’re actually working within. That requires stakeholder interviews, competitive audits, honest content inventories, and a clear-eyed look at the existing tech stack. Skip it and you’ll spend the next three months patching over assumptions no one tested in the first place.

Architecture decisions live here too. Are you running WordPress as a traditional PHP-based CMS, or decoupling it into a headless setup with a Next.js front end? That’s not a development question. It’s a business question, and the answer depends on your publishing workflow, performance targets, third-party integrations, and whoever will maintain the site after launch. If you’re still weighing platforms entirely, our breakdown of WordPress vs Webflow vs other CMS options covers those trade-offs directly.

Good discovery produces outputs you can actually use. A site map. A content model. A list of integrations covering CRM, analytics, marketing automation, and e-commerce. Measurable success criteria. Without those four things in writing, “design” is just decoration applied to guesswork.

Information architecture comes before everything else in development

WordPress organises content as posts, pages, and custom post types. How you model those types determines whether editors can publish a case study on their own or need to file a ticket with a developer every single time. That’s a real business cost. It compounds over years.

Answering the right questions here matters more than people think. How many distinct content types exist? What relationships exist between them? Which fields belong to an editor and which should be locked to prevent breakage? Tools like Advanced Custom Fields or the native block editor give you precise control, but only if someone has mapped the taxonomy before a single line of code is written.

A content model is not a sitemap. A sitemap shows pages. A content model shows the data structure behind those pages, including how fields relate, what’s reusable, and where editorial governance starts and stops.

URL structure, internal linking logic, multilingual strategy if it applies. All of it belongs here. These decisions are expensive to reverse six months after launch. Kicking them to a “phase two” that quietly never materialises is one of the most common and costly mistakes in WordPress projects.

UX before visuals. No exceptions.

Wireframing and UI design are not the same activity. A lot of agencies propose them as a bundled phase. That’s a mistake, and it usually benefits the agency’s timeline, not your site.

Wireframes define layout, hierarchy, and interaction logic. They’re deliberately plain: grey boxes, dummy text, no brand colour anywhere. The entire point is to confirm that users can find what they need and complete an intended action before anyone argues about button radius or font choice. Visual design follows once those structures are validated.

Doing both simultaneously sounds efficient. It isn’t. When stakeholders review a fully branded page, they fixate on the logo position or the typeface instead of asking whether the page structure actually works. Separating the phases keeps feedback productive. Our digital product services run in a deliberate sequence for exactly that reason: Discovery, Brand and Strategy, UX and Wireframes, UI and Animation.

One thing worth saying plainly: a design system built for WordPress is not a generic Figma library with a WordPress logo dropped on the cover. Every component has to account for editorial reality. Can an editor swap an image? Add a fifth card to a row designed for four? Break the layout with a 200-word headline? The system needs real constraints, not optimistic assumptions about how content will behave.

What the engineering work actually involves

This is where the gap between a capable agency and a template shop becomes visible. A custom WordPress build has several distinct engineering layers, and most proposals flatten them into a single line item called “development.”

Theme architecture. A modern WordPress theme runs on block-based Full Site Editing or a classic theme using a templating engine like Blade (via Sage/Roots) or Timber/Twig. Block themes are WordPress’s stated direction. Classic themes still dominate complex enterprise builds because of their maturity and compatibility with the plugin ecosystem. Neither choice is universally correct, and anyone who tells you otherwise is oversimplifying.

Plugin decisions. There are over 59,000 plugins in the official WordPress directory. Choosing correctly means evaluating update frequency, security track record, performance overhead, and hosting compatibility for each one. A responsible build minimises plugin count and uses purpose-built code for anything central to the site’s function. Every plugin is a dependency you’ll maintain for years. Treat them that way from the start.

Performance engineering. WordPress can be fast. It is not fast by default. Real performance work covers image optimisation pipelines (WebP and AVIF with responsive srcsets), critical CSS extraction, JavaScript deferral, server-side caching via Redis or Memcached, page caching through Varnish or a CDN edge layer, and database query optimisation. The benchmarks are Google’s Core Web Vitals: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Those are the numbers your proposal should reference explicitly.

Accessibility. WCAG 2.2 AA compliance is a legal requirement in many jurisdictions. Not a nice-to-have. Accessible WordPress development means semantic HTML, logical heading hierarchy, full keyboard navigation, ARIA attributes where native semantics fall short, and colour contrast ratios of at least 4.5:1 for body text. Automated scanners like axe-core catch roughly 30 to 40 percent of issues. The rest requires manual testing with screen readers and keyboard-only navigation. There’s no shortcut, and automated-only audits should raise a flag on any proposal.

Security. WordPress is the most targeted CMS on the web, purely because of its market share. A secure build includes hardened file permissions, disabled XML-RPC if unused, rate-limited login endpoints, HTTP security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), and an active dependency update policy. Managed hosts like WP Engine or Cloudways handle infrastructure-level security. Application-layer security stays with the development team regardless of who hosts the site.

Content migration always takes longer than anyone estimates

If you have an existing site, migration is probably the most labour-intensive phase of the project. It’s also the one most consistently under-scoped in proposals, sometimes because agencies underestimate it, sometimes because they’d rather not scare you with the number.

Moving 500 blog posts from a legacy CMS to WordPress is not a copy-paste job. It involves mapping old content types to new ones, cleaning up years of accumulated markup, setting up redirects for every old URL, validating internal links, and confirming that metadata, authorship, and publication dates transfer correctly. A botched migration can erase years of organic search equity in a single afternoon. The redirect map alone can take days on a large site.

If a proposal says “content migration: included,” ask exactly what that covers. How many pages? What about images, PDFs, and embedded media? Who handles editorial review of the migrated content once it lands in the new CMS? Vague answers here predict expensive surprises later.

QA, staging, and what launch actually involves

QA on a WordPress project is not clicking through the site on one browser. It covers cross-browser testing (Chrome, Firefox, Safari, Edge at minimum), responsive testing across real device breakpoints (tablet orientations, large monitors, small Android devices, not just “mobile and desktop”), accessibility audits, performance benchmarks, and functional testing of every form, integration, and dynamic element. Every single one.

A staging environment that mirrors production exactly is non-negotiable. The same PHP version, same hosting configuration, same CDN setup, same SSL certificate chain. Differences between staging and production are precisely where launch-day surprises hide. “It works on my local” is not a launch strategy. It’s the sentence before something breaks.

The best QA process catches defects before the client does. The second-best has a clear, shared protocol for reporting and resolving defects after launch. Every project needs both.

Launch is a coordinated event. DNS propagation, SSL verification, redirect activation, analytics and Tag Manager configuration, Search Console submission, cache warming, and a post-launch monitoring window. A responsible team watches Core Web Vitals, uptime, and error logs for at least 72 hours after go-live. If your agency calls it done the moment the DNS propagates, that’s worth asking about upfront.

What keeping a WordPress site healthy actually requires

A WordPress site isn’t a static asset you deploy and forget. WordPress core updates, theme updates, plugin updates. Each update cycle introduces compatibility risk, which is why updates should run on staging first and get tested before promotion to production. Security patches are the exception. Apply those immediately, even if it means a brief maintenance window.

Ongoing maintenance also means performance monitoring, uptime checks, daily backups with tested restore procedures, and periodic content audits. If the site depends on third-party APIs (a HubSpot form, a booking engine, a product feed), those integrations need monitoring too. APIs change. Endpoints get deprecated. Authentication tokens expire without warning. Someone has to be watching for all of it, and that someone should be named in your maintenance agreement before you sign anything.

You can review the projects we’ve delivered to see how these phases come together on production sites for established brands.

FAQs

How long does a custom WordPress website design project take?

A typical custom WordPress build for a mid-size brand takes 10 to 16 weeks from discovery through launch. Complex sites with extensive integrations, multilingual requirements, or large content migrations can run 20 weeks or more. Discovery and content modelling often drive the overall timeline more than design or development do.

What is the difference between a custom WordPress theme and a premium theme?

A premium theme is a pre-built template purchased from a marketplace like ThemeForest. A custom theme is engineered from scratch to match your specific design system, content model, and performance requirements. Premium themes ship with features you’ll never use, which adds code bloat and long-term maintenance overhead. Custom themes contain only what your site actually needs.

Do I need a headless WordPress setup?

Headless WordPress (using the REST API or WPGraphQL with a front-end framework like Next.js) makes sense when you need to serve content across multiple channels, require very high performance scores, or already have a JavaScript-heavy front-end team. For most marketing sites with a single web presence, a well-built traditional WordPress theme delivers comparable performance with considerably lower complexity and cost.

How do I evaluate a WordPress agency’s proposal?

Look for a clearly defined discovery phase, a documented content model, a component-based design system, explicit performance and accessibility targets, a detailed migration plan if applicable, and a post-launch maintenance agreement. If the proposal skips any of those, ask why. Vague proposals produce vague outcomes.

What does WordPress website maintenance cost?

Ongoing maintenance typically runs between $500 and $3,000 per month depending on site complexity, update frequency, hosting tier, and whether the retainer covers content changes or feature development. The cost of skipping maintenance is higher: security breaches, performance degradation, and plugin incompatibilities compound quickly over time.