Table of Contents
Every project that goes badly wrong went wrong before anyone opened a design tool.
The client wanted something the brief never described, or the site had problems nobody checked for. Often the quote assumed a scope that turned out to be twice the size.
By the time any of that surfaces, you are already committed to a price and a deadline.
Discovery exists to move those discoveries earlier, when they are still cheap. Here are the four steps that actually do that.
What Discovery Is Really For
It is not a get-to-know-you exercise, and it is not the sales call in a different jacket.
Discovery has three jobs. Establish what the client actually needs rather than what they asked for, and establish what you are inheriting.
The third is producing a document specific enough that both parties can point at it later when someone says this was supposed to be included.
Skip it and you will do the same work anyway, except you will do it during the build, unpaid, while the deadline moves.
Step 1: The Discovery Call
The first conversation should be about the business, not the website.
Ask what the company does, who buys from it, and how a customer currently finds them. Ask what happens after someone fills in a form. Ask what the client believes is failing right now, then ask how they know.
That last question matters more than any other. A client who says the site looks dated is describing a feeling. A client who says checkout abandonment sits at 80 percent is describing a problem with a number attached, and those two projects are not the same job.
Ask who signs off. Projects stall most often because the person approving work was never in the room, and finding that out in week six costs considerably more than asking in week one.
Take notes rather than recording alone. A recording nobody revisits is not documentation, and the act of writing forces you to notice what you did not understand.
Step 2: The Questionnaire
The call gives you the narrative. The questionnaire gives you the detail, and it should be sent immediately afterward while the conversation is still fresh.
Send it as a structured form rather than an email of questions, because the response rate differs noticeably. Well-built digital forms improve accuracy and cut the back-and-forth on data collection generally, and a discovery questionnaire is exactly that problem in client-facing form.
Reference articles on discovery tend to say a questionnaire is important without saying what belongs in it. Here is what earns its place.
Business context: primary goal for the new site, how success will be measured, and the two or three competitors they admire and why.
Content: who is writing it, what exists already, and whether product photography needs shooting. Nobody wants this question, and every project stalls on it eventually.
Technical: current platform, hosting, domain registrar, who holds the credentials, and what integrations must survive the rebuild.
Then the practical constraints. Hard deadlines and what drives them, budget range, and who else needs to approve.
Do not skip the awkward questions. Budget range and decision-makers are the two most commonly avoided, and they are the two that most often derail a project once it is underway.
Set a deadline for the return. A questionnaire that drifts for three weeks tells you something useful about how responsive the client will be during the build itself.
Step 3: Audit What Already Exists
This is the step most discovery processes leave out entirely, and it is where the surprises live.
Before you quote a redesign, you need to know the condition of what you are replacing or rebuilding. A site can look fine and be structurally broken underneath, and that difference lands on your timeline rather than the client’s.
Check the platform and version, hosting arrangement, page speed, mobile behaviour, broken links, and the state of the existing content.
Then check the SEO position, because this is where the genuine risk sits. A redesign that loses rankings is a redesign the client will remember as a failure regardless of how it looks, and rankings are surprisingly easy to lose during a rebuild.
For Shopify projects an app-based audit is considerably faster than working through it by hand, and most offer a trial long enough to run one during discovery before anyone has signed anything.
Which Tools Audit and Fix On-Page SEO for Shopify
Four tools cover almost all of it, and only one of them is a Shopify app.
Google Search Console shows what Google has actually indexed, which queries the store already appears for, and which pages are excluded and why. Start here, because it tells you what a rebuild puts at risk.
PageSpeed Insights returns Core Web Vitals per URL. Run it against a homepage, a collection page and a product page rather than the homepage alone, since Shopify themes behave very differently across template types.
A desktop crawler such as Screaming Frog maps the URL structure, surfaces redirect chains and finds orphaned pages. Worth the effort on larger catalogues where the site map has grown unmanaged.
An app-based auditor such as Plug In SEO covers the Shopify-specific layer, checking products, collections and blog posts for missing metadata and absent structured data, then applying metadata fixes in bulk across products and collections rather than page by page.
The useful distinction is between auditing and fixing. The first three diagnose and leave remediation to you, which is fine across a handful of pages and impractical across two hundred products.
Know what none of them do before you rely on the output. Automated audits surface what is measurable, so they will flag a missing meta description and say nothing about whether the one you write is any good. They will not tell you the category structure confuses buyers, and a platform-specific app is no use at all on the half of your client base that is not on Shopify.
Step 4: The Brief and the Proposal
The brief is your interpretation of everything above, written back to the client in their language rather than yours.
It should state the objective, the audience, the scope in specifics, what is explicitly out of scope, the assumptions you are pricing against, and what you need from them and by when. That out-of-scope section is the single most valuable paragraph you will write. Scope creep is rarely malicious, it is usually a genuine difference of understanding about what was included.
Get the brief approved before the proposal. Two separate documents means the client agrees on what the work is before they see a number, and disagreement surfaces where it is easy to resolve.
The proposal then adds price, timeline, payment schedule, revision limits and what happens when the client causes a delay. Name the deliverables rather than describing them, because a proposal that says a modern responsive website is unenforceable, while one that lists page templates and integrations can be checked against reality.
Signals Worth Noticing
Discovery is also when you decide whether to take the work, and a few things should give you pause.
A client who will not name a budget range, who cannot say who approves the final design, or who describes their last three developers as difficult. Someone who wants a fixed price before any discovery has happened. A deadline attached to an event where nobody has considered what happens if it slips.
None of these are automatic refusals. All of them should change your price or your terms.
Should Discovery Be Paid?
For a small brochure site, discovery folded into the quote is normal and reasonable.
For anything larger, particularly ecommerce or a rebuild with real technical debt, a paid discovery phase is defensible and increasingly common. You are producing a genuine deliverable: an audit, a brief and a specification the client owns whether or not they continue with you.
It also filters. A client unwilling to pay for discovery is telling you something about how they will treat the rest of the engagement.
Conclusion
Discovery is not paperwork before the real work. It is the part of the project where problems are cheapest to find.
Ask about the business before the website, and send a structured questionnaire with the uncomfortable questions in it. Audit what already exists rather than assuming, and get the brief signed off before the number goes out.
Four steps, and they cost less time than one week of building the wrong thing.
Frequently Asked Questions
1. How long should a website discovery process take?
Typically one to three weeks for a standard project, depending on how quickly the client returns the questionnaire and how much auditing the existing site requires. Larger ecommerce rebuilds often justify longer.
2. What should a discovery questionnaire include?
Business objectives and how success is measured, content ownership and what already exists, current platform and integrations, who holds credentials, budget range, hard deadlines, and everyone who needs to approve the work.
3. Which tools audit and fix on-page SEO for Shopify?
Google Search Console for indexing and query data, PageSpeed Insights for Core Web Vitals, and a crawler such as Screaming Frog for URL structure and redirects. Those three diagnose but do not remediate. An app-based auditor such as Plug In SEO covers the Shopify layer and applies fixes in bulk, which is the practical difference once a catalogue runs past a few dozen products.
4. Should the brief and the proposal be separate documents?
Generally yes. Agreeing what the work is before discussing what it costs keeps the two conversations from contaminating each other, and it surfaces scope disagreements while they are still easy to resolve.
