Website Strategy Consultant: What Good Discovery Actually Covers

Most people hire a website strategy consultant and get a moodboard. That is a design exercise wearing a strategy badge. Strategy, in this job, is a set of decisions the build can actually follow: who the site is for, what it sells, how pages are structured, what proof sits next to the risky claims, which URLs already work in search, and how content will be stored once the designer leaves.

I take this work because I also build the sites. Discovery that cannot survive contact with Webflow, Framer, or Next.js is theater. If the output is only color, type, and a 'vibe,' you did not buy strategy. You bought a Pinterest board with an invoice.

Google still ranks pages that answer a real query with useful content. That is the bar in Google's people-first content guidance. A consultant who never inventories those pages is decorating around an asset they have not measured.

What you are actually hiring

A website strategy consultant should leave you with artifacts, not adjectives. The job is to make the next 90 days of design and build cheaper because fewer arguments are still open. If every meeting still starts with 'who is this page for,' discovery failed.

The useful version of the role sits between marketing, sales, and whoever will implement. It is not a fractional CTO. It is not a product consultant for an authenticated app. It is the person who can say, in writing, what the public site must do, and what it must not try to be.

• A named ICP, including who you will turn away.
• A primary offer per money page, in one sentence.
• An information architecture that matches how people actually buy.
• A proof map: what exists, what is public, what stays off the site.
• An SEO inventory of URLs that already earn clicks or links.
• A CMS model a marketer can operate without opening Designer or VS Code.

If discovery produced slides and no schema for the CMS, you are not ready to design.

Discovery deliverables vs moodboards

Moodboards are optional. They can help a founder see tone. They cannot tell a developer which collection fields to create, which nav items to kill, or which blog posts to keep. I treat visual direction as a later pass, after the decision set exists.

Good discovery is boring on purpose. You interview sales. You read the last 20 inbound emails. You crawl the current site. You sit with whoever publishes blog posts and watch them fail to add a field. Then you write the artifacts down so the designer is not guessing.

What a moodboard cannot decide

• Whether case studies live at /work or /blog.
• Whether booking is the primary action or a form is.
• Whether the blog is a ranking engine or a thought-leadership dump.
• Whether localization is real or a language toggle that 404s.

ICP and the offer, on paper

ICP is not a persona poster with a stock photo. It is a description of the buyer who can pay, decide, and complete the path you will put on the site. For a service business, that usually means role, company shape, trigger, and the objection that kills the call.

The offer is the sentence the page must earn. 'We build websites' is not an offer. 'We rebuild marketing sites in Next.js and Sanity without dropping the URLs that already rank' is closer. If two service pages share the same sentence, one of them should not exist.

Write who it is not for. That sentence raises conversion among the people you do want, and it stops the discovery from turning into a 40-page menu. A website strategy consultant who will not constrain the offer is collecting requirements, not making decisions.

I run ICP work from sales artifacts, not from a workshop icebreaker. Sit in on two calls. Read the last month of inbound. Ask what deals died after the site visit. You will hear the same three objections. Those objections belong on the page, in the IA, and in the proof list. If they only live in a sales script, discovery is incomplete.

Offer hierarchy is the part founders skip because it feels political. Someone wants a page for every capability. Strategy is choosing the one or two offers the site will actually sell this quarter, and demoting the rest to supporting copy. If every nav item is equal, none of them is the business.

Once the offer is specific, the layout work is much smaller. That sequencing is the same argument I make in conversion-focused web design: pipeline moves when the next step is obvious, not when the hero is louder.

Information architecture that sales can use

IA is the map of jobs, not a sitemap exported from a tool. Home, offer pages, proof, about, and a path to book or inquire. Extra pages need a job or they become navigation noise. If sales still sends PDFs because the site cannot explain scope, the IA is incomplete.

I sketch IA as a set of questions each template must answer. The service page answers scope, process, who it is not for, and the action. The case-study template answers context, constraint, and what changed, without invented percentages. The blog template answers one search job per URL.

1. List every current URL that gets traffic or inbound links.
2. Group them by job: attract, explain, prove, convert, support.
3. Mark merges, kills, and keeps before anyone designs a new nav.
4. Name the primary template for each job. Do not invent a new template per campaign unless you will maintain it.

Nav politics will try to reopen this. A founder wants 'Platform' in the header because a competitor has it. A sales lead wants six industries. Write the job of each link. If the link cannot be completed with a sentence ('this page exists so X can do Y'), it is a vanity label. Discovery should kill vanity labels before design makes them look expensive to remove.

Also decide the relationship between blog and money pages. A blog that never links to the offer is a magazine. An offer page that never links to the guides that already rank is leaving internal equity on the table. IA includes those connections, not only the top nav.

Proof architecture, not a testimonials dump

Proof is a strategy problem because it is scarce and legally sensitive. Discovery should list what you can actually show: named public quotes, process specificity, product screenshots you own, and project narratives without fake revenue. A footer logo row is not a proof architecture.

Place proof next to the claim that creates risk. Price, timeline, 'have you done this in our stack,' and 'will we own the CMS' are the usual ones. If those answers live in a sales deck and not on the site, the consultant left the hard work to the closer.

SEO inventory as a discovery deliverable

If the company already has a site, strategy that ignores Search Console is malpractice. You do not need a 40-page audit to start. You need the URL inventory, the top landing pages by clicks, and the indexation surprises (noindex on money pages, duplicate hosts, a blog the new nav is about to orphan).

I run that capture with the same sequence as my technical SEO audit checklist. Strategy then decides which of those URLs stay, merge, or redirect. Design does not get to 'simplify' a ranking URL because it did not fit the new grid.

Helpful content still has to be findable. Google's crawler and indexing docs are the baseline, not a vendor's SEO score. If discovery never opens Google Search Central and Search Console, the consultant is guessing which pages matter.

The CMS model before the first component

A CMS model is strategy because it decides who can publish after launch. Collections, references, SEO fields, and which content is a page versus an item. If the model is 'we will figure it out in Webflow,' you will pay twice: once to design, once to rebuild the CMS when marketing needs a field.

Write the fields in a table, not in a meeting. For a case study: client-safe title, industry, stack, problem, constraint, outcome narrative, media, related services, SEO title, meta description, slug, OG image. For a blog post: author reference, category, takeaways, FAQ items if they will appear on the page, canonical if needed. If a field will not be edited by a human, do not put it in the Editor. Developers can compute reading time.

• Every repeating content type gets a collection or schema, not a static page copy-paste.
• Title, meta description, slug, and OG fields are first-class, not an embed at the end.
• Authors, categories, and FAQs are structured if you will reuse them.
• The Editor or Studio role can complete a publish without a developer.

How this differs from a fractional CTO

A fractional CTO owns architecture bets, hiring, vendors, and what to stop building in the product. A website strategy consultant owns the public site as a commercial system. Mixing the titles is how you get a homepage that explains the tech stack and never names the offer.

If the real bottleneck is engineering leadership, read when fractional CTO services actually help. Do not hire that role to pick button copy. Do not hire a website strategist to choose your auth provider.

I do website strategy through ZedNova Studios because I also implement. That is a bias. It means I will not sign off on an IA the CMS cannot support. It also means I will tell you when you need a product owner for the app, not another marketing sitemap.

A week of discovery I will actually run looks like this. Days 1-2: crawl, Search Console, inbound, two sales conversations. Days 3-4: draft IA, offer sentences, keep/merge/kill URLs, CMS table. Day 5: walk the pack with the person who will build and the person who will publish. If they cannot estimate and cannot picture an Editor workflow, the pack is not done.

If you want discovery that produces ICP, IA, offer, proof, SEO inventory, and a CMS model you can build against, that is the call I take. Bring the current site and the last month of inbound. Leave the moodboard for week three.