Many website proposals open with a line called discovery, sometimes as a separate contract with its own fee and the price of the site itself to follow. A website discovery phase can be the most useful money spent on a project, or a run of meetings that ends in a slide deck of sticky notes nobody opens again.
The difference is what it investigates and what you own at the end. This guide covers what happens in discovery, what you should receive, which projects justify paying for it separately, and how to prepare.
The short answer
A website discovery phase is the structured first stage of a project, where goals, users, content and technical limits are investigated before design starts and, often, before the full price is fixed. It usually includes stakeholder interviews, a review of analytics and Search Console data, a content inventory, customer and competitor research, a technical review, and an agreed sitemap and scope.
It is worth paying for separately when a project carries expensive unknowns: integrations with other systems, many stakeholders, a large content migration or several languages. For a simple site with one decision-maker and content mostly ready, a good brief and a thorough consultation usually cover the same ground.
Either way, the result should be written requirements specific enough for any competent provider to price the build.
Why discovery exists
In web design, what drives cost and timeline is mostly invisible at the brief stage. For example:
- “Connect the site to our CRM” can mean a form that drops leads into a CRM inbox, or a two-way sync of contacts, custom fields and consent records. The first is a modest configuration task; the second is a project in its own right.
- “Move the news section across” can mean 40 articles or 4,000, with or without attached PDFs and versions in several languages.
Quoting a fixed price without knowing which you mean forces a provider to pad for the worst case or quote the best case and argue later. Discovery removes the guesswork for both sides.
It is also where the disciplines meet. A website isn’t simply a visual design project: strategy, UX, content, development, performance, SEO and conversion all depend on each other’s decisions, and discovery weighs them together before any is locked in. It is where your website strategy becomes requirements a designer and developer can work from.
Your brief records what you know and want; discovery tests it against data, customers and technical reality. A strong website brief makes discovery shorter, but on a complex project it doesn’t replace it. In the stages of a website project, discovery comes after the brief and before any design.
What happens in a website discovery phase
A thorough discovery covers seven areas.
1. Stakeholder interviews
Short one-to-one conversations with the decision-maker, sales, customer service, marketing, the site’s future editors and whoever manages connected systems.
Why one-to-one. In a group, the most senior voice tends to set the direction. Heard separately, sales may want more enquiries, HR better recruitment and leadership a repositioned brand, all from the same homepage. Discovery should bring those conflicts into the open and get a decision on priority, not quietly try to satisfy everyone.
Expect questions like these. What must the site achieve in the next year? What do customers ask before they buy? What goes wrong with the current site? Who approves what?
2. An analytics and Search Console review
Google Analytics shows where people land, their devices and languages, and whether enquiries are tracked as key events (what it used to call conversions). Search Console’s Performance report shows the queries you already appear for and the pages that bring in search traffic.
On a redesign, this identifies the pages whose search traffic must be protected with redirects, a core input to any migration SEO checklist. It often reveals the numbers can’t be trusted: no key events set up, duplicate tracking or forms nobody measures. Better to learn that now than after launch.
3. A content inventory
Every page on the current site with its purpose, traffic, owner and a verdict: keep, rewrite, merge or remove. It should also capture content outside the site, such as brochures, sales presentations and the answers your team repeats in emails every week.
Why it matters. The inventory sizes the content job, often the part of a project that runs late. On a multilingual site, run it per language, because versions drift apart. Your website content plan builds directly on it.
4. Customer research
Conversations with recent customers, sales call notes, enquiry emails and support tickets. The aim is to learn the words customers use, the questions they ask at each stage, and what nearly stopped or finally convinced them.
A handful of honest conversations often teaches more than a long survey. The findings feed a map of the customer journey, matching each audience’s questions to the pages that will answer them.
5. Competitor and search review
Not to copy rivals, but to see what buyers compare you with: how competitors explain services and present prices and proof. Searching for your main services also shows what kind of page Google ranks for each, which tells you the intent your pages must match. Our guide to keyword research and search intent covers the method.
6. A technical review
The current platform and hosting, the systems the site must talk to (CRM, booking, ERP, email marketing), third-party scripts, who owns the domain and holds the logins, and any legal or accessibility obligations. Much of a project’s hidden cost lives here, which is why website integrations deserve a precise description rather than a line on a wish list.
7. Sitemap, scope and priorities
Everything above becomes decisions: a sitemap, the page templates it needs, features ranked must-have, should-have and nice-to-have, and a plain statement of what is out of scope. This is what the build is priced against.
What you should receive at the end
Whatever the format, expect these outputs:
| Deliverable | What it contains | Why you need it |
|---|---|---|
| Findings summary | Goals, a few website KPIs, what interviews and data showed, open questions | One reference everyone signs off before design |
| Audience and journey map | Main audiences and their questions at each stage | Shapes page structure and content |
| Content inventory | Every existing page with a verdict, plus the gaps | Sizes the content job |
| Sitemap and requirements | Pages, templates, integrations, forms, languages, editing needs | The basis for design, build and price |
| SEO baseline | Current search traffic, pages to protect, an outline redirect plan | Protects search visibility on a redesign |
| Scope and proposal | What is in and out, with a price and timeline for the next phase | Turns research into a commitment |
The test of good discovery. Could another competent provider price your build from these documents? If yes, you paid for real work you now own. If the output is mostly workshop photos and brand adjectives, you paid for meetings.
When a paid discovery phase is worth it
Separate, paid discovery earns its fee when unknowns would otherwise become change requests, delays or a padded quote. Look for these signals:
| Signal | Why discovery pays off |
|---|---|
| Integrations with a CRM, booking system or ERP | One-line requests can hide very different amounts of work |
| Many stakeholders or departments | Competing goals surface before design, not at sign-off |
| A large content migration | Hundreds of pages and PDFs need sizing before anyone can quote |
| Several languages | Versions drift, markets differ, each language needs its own SEO |
| Significant search traffic today | Pages to protect are identified before the sitemap changes |
| Legal or accessibility duties | Requirements are known before design, not retrofitted |
As a rule of thumb, if two or more apply, paid discovery is money well spent. With several languages especially, planning a multilingual website raises questions that are hard to settle inside a quote.
When a brief and a consultation are enough
A site of a handful of pages, one or two decision-makers, content mostly ready, nothing to connect beyond forms and analytics, or a single campaign landing page: these rarely need a separate phase. A thorough brief and a provider who asks good questions before quoting cover the ground, so discovery happens inside the proposal process. If a simple project comes back with a long paid discovery attached, ask what it will find that a consultation can’t.
The middle ground: discovery scoped to the risk
Many projects are simple apart from one risky area, such as a CRM integration or thousands of posts to migrate. Ask for discovery focused on that area alone: a smaller commitment that removes the unknown most likely to make the quote unreliable.
Questions to ask before you pay for discovery
For how discovery fits into fixed-price, hourly and retainer work, see website pricing models.
How to prepare for a discovery phase
- Name one decision-maker. List the stakeholders to interview and book their time early. Too many people with a veto is a classic reason website projects fail.
- Grant access before kick-off. Google Analytics, Search Console, hosting, the CMS and the domain registrar, each as a named user account rather than a shared password.
- Gather what exists. Brand guidelines, sales presentations, brochures, earlier research and a sample of recent enquiries with personal details removed.
- Write down the non-negotiables. Deadlines, a budget range, events the launch must meet and legal requirements.
- List your systems and their owners. Note who manages the CRM or booking system, and whether it can share data.
- Line up customers to talk to. A few recent customers willing to take a short call, and ideally a prospect who chose a competitor.
Frequently asked questions
What is a website discovery workshop?
It is one format within discovery: a structured session where stakeholders agree goals, audiences and priorities together. It helps alignment, but doesn’t replace one-to-one interviews, a data review or a content inventory.
How long does a website discovery phase take?
It depends on how many people need interviewing, how much content needs reviewing and how quickly access is granted. Discovery focused on a single risk can take days; a multi-department, multilingual project can take weeks. Either way, the end date belongs in writing.
Is a discovery phase the same as a website audit?
No. An audit measures how the current site performs: speed, mobile use, search visibility and security. Discovery uses those findings as one input, alongside goals, customers, content and requirements, to plan the next site.
What to do next
Discovery isn’t a ritual before the real work. It is the real work of deciding what the website must do, and for whom, before anyone pays for design. Whether it needs its own contract depends on how many expensive unknowns your project carries.
If you are planning a new site, our website design and development service starts with a strategy session and a sitemap before any design. If you already have a site, a free website audit gives you performance evidence to bring to the first conversation. Or talk to us about your project: a free 30-minute consultation is a good place to work out how much discovery it really needs, and what to prepare in the meantime.