What Really Happens Inside a Web Design Project
Most people think a web design project starts when a designer opens Photoshop and ends when a site goes live. The reality is messier, slower, and far more interesting than that. A lot of the work that makes the difference between a site that performs and one that just sits there happens before a single page is built, and long before the client ever sees a design. Understanding what that work actually looks like helps you work with a designer better, and it helps you understand why the quotes you receive vary so wildly.
On this page
Discovery, the bit most people skip
Before anything gets designed, someone needs to understand the business properly. That means asking questions that feel obvious but rarely have simple answers. Who is the target customer? What action should a visitor take? What does the site need to rank for? What does the competition look like in search results?
Skip this stage and you end up building something that looks fine but does nothing useful. A physiotherapy clinic in Coventry does not need a website that impresses other designers. It needs one that appears when someone searches “physiotherapist Coventry” and makes it easy to book. Those are different briefs, and getting the brief right shapes every decision that follows.
Structure before design
The page layout, the navigation, the URL structure, the internal linking, how many pages are needed and why , this is the architecture stage, and it is also where SEO and design either come together or they do not. Get it wrong and you can spend months trying to fix a site that refuses to rank, without ever being entirely sure why.
Common traps include too many thin pages that split authority, navigation that buries important content three clicks deep, and URLs that were auto-generated and never revisited. None of this is visible to a visitor. All of it matters to Google.
This is also where decisions about why a project takes the time it does start to make sense. Architecture done properly is not fast work.
The build phase
Theme and template choices
On WordPress, which powers the majority of small business sites, this is where the under-the-bonnet decisions happen. Which theme or framework? Are page builder plugins involved, and if so, how much overhead do they add? Are custom post types needed? How will the site handle images, fonts, and scripts without getting slow?
These choices have real consequences. A site built on a heavy multipurpose theme with four plugins doing the job of one will load slowly, score poorly on Core Web Vitals, and be a nightmare to update two years later. A site built leaner, with code that only does what is needed, tends to hold up much better over time.
Content and copy
This is where most projects stall.
The designer is waiting for the client to send copy. The client is waiting to see a design before writing anything. Neither wants to go first, and the project sits idle for two weeks. It is a very predictable bottleneck and it almost always traces back to the same root cause, content was treated as something to sort out later rather than planned at the architecture stage alongside everything else. Copy written around a clear brief, rather than forced into a template after the fact, almost always reads better and converts better.
SEO built into the build, not applied afterward
A common approach is to build the site first, then hand it to someone for SEO. The problem is that SEO baked in from the start, at the structure and content stage, outperforms SEO applied as a retrofit. Title tags, meta descriptions, heading hierarchy, schema markup, page speed, internal linking, these are not finishing touches. They are part of the architecture, and treating them as an afterthought shows in the results.
The Godiva Physiotherapy website is a clear example of this in practice. Built properly from the ground up in 2023, it still holds the top position for key physiotherapy search terms without any ongoing SEO spend. That is what happens when the technical foundations are right from day one.
Testing before launch
Speed tests, mobile display, form submissions, browser checks, broken link scans, redirect logic, robots.txt, sitemap submission. The pre-launch checklist on a well-run project is long. Most of it is invisible to the end client, and none of it is optional.
A site that goes live with a disallowed crawl directive in robots.txt will not appear in Google search results at all. It has happened. It happens more than people admit, and it is exactly the kind of thing a thorough pre-launch check catches before it becomes a serious problem for the client.
After launch
Going live is not the finish line. A new site needs time to be crawled, indexed, and assessed by search engines, and pages need to earn rankings through relevance and authority. That process is measured in weeks and months, not days, and no amount of anxiety speeds it up.
The best thing a client can do post-launch is resist the urge to start redesigning things because rankings have not moved in a fortnight. The work has been done. Give it room to land.