What a company website is actually for

Ask the person who commissioned a company website what it's for, and you will almost never get an answer that names a metric. You'll get "our digital presence." You'll get "so we look legitimate." You'll get "it's 2026, you need one." Ask the same question about the CRM, the invoicing tool, or the phone system, and the answer arrives instantly, because those tools have a job and everyone in the building knows what it is. The website is the one piece of company infrastructure that gets built, paid for, and re-designed every few years without ever being asked what it's supposed to do.

This isn't a design problem. Redesigns don't fix it, because a new template applied to an undefined job produces the same undefined job in nicer type. It's a scoping problem, and it happens upstream of anything a designer or a developer touches — usually in a meeting where "we need a new website" gets agreed on before anyone asks a harder question: a new website that does what, for whom, measured how.

Here is the claim this piece is going to defend: there are exactly four jobs a business website can do. Get a stranger to find you. Convince someone who has already found you. Let an existing customer solve their own problem without calling you. Give a salesperson something to send. A site can do more than one of these — plenty of good sites do two — but a site that tries to do all four at once, with no stated priority between them, does the first two badly, because those two actively fight each other for the homepage.

The four jobs, and the metric that proves each one is real

Job one: get found by someone who wasn't looking for you specifically. This is organic search and, less often now, paid search. The metric is not traffic — traffic is a vanity number that goes up when a blog post ranks for a term nobody buying anything searches for. The real metric is qualified sessions that convert to an inquiry, a demo request, or a sale, tracked back to a specific landing page. If you cannot say which pages on your site bring in people who become customers, you are not doing this job, you are hosting an SEO experiment with no scoreboard.

A site built for this job looks a certain way almost regardless of industry: dozens to hundreds of narrow pages, each answering one query a buyer actually types, a blog or resource section that exists because it ranks rather than because someone enjoys writing it, and a content team or a retained agency that treats the site as a product with a backlog, not a brochure that gets touched once a year. This is expensive in a way most companies underestimate, because the expense is recurring — content production, technical SEO maintenance, link building — not a one-time build cost. If nobody at your company is willing to own that as an ongoing function, don't build for this job. You'll get a beautiful site that ranks for nothing and everyone will quietly agree the redesign "didn't work," when what actually didn't happen was the six months of unglamorous content work the design was supposed to sit on top of.

Job two: convince someone who already knows your name. This is the site a prospect visits after a referral, after a cold email, after seeing you speak at an event, or mid-way through a sales process because their procurement team asked "do they have a real website." Nobody is searching for you by category here — they typed your name, or clicked a link someone sent them. The metric is completion of a specific next action from a person you can trace: booked a call, filled the form tied to that referral source, replied to the follow-up email referencing something specific from the site.

This job needs far fewer pages than job one and a completely different homepage. A homepage optimized for search wants breadth — categories, entry points, keywords woven through headers. A homepage optimized for convincing a warm visitor wants depth on a narrow claim: what you do, for whom, proof that you've done it before, and a single obvious next step. These two homepages are not compatible, which is why a site trying to do both usually ends up with a homepage that hedges — a little bit of everything, decisive about nothing — and satisfies neither audience.

Job three: let an existing customer solve their own problem without picking up the phone. Documentation, a status page, a knowledge base, account self-service, order tracking. The metric here is the most concrete of the four: support ticket or call volume for the questions the self-service content is supposed to answer. If those tickets don't drop after the pages go live, the pages aren't doing the job, regardless of how they look. This is also the job most likely to get bundled into "the website" by habit when it should really be its own product with its own owner — usually someone in support or customer success, not marketing.

Job four: give a salesperson something concrete to send. This is the job almost nobody names out loud, and it's the one this piece spends the most time on below, because it's the one where the instinct to chase traffic actively works against you.

Why "brand credibility" doesn't belong on this list

Every company that can't name one of the four jobs falls back on a fifth, unstated one: credibility. The site exists so the company looks real. This sounds reasonable and it is almost never treated with the rigor it needs to actually be true.

Credibility is not a job — it's a side effect that any of the four real jobs produce automatically, as long as the site is competent. A site that ranks for the right search terms is, by definition, credible to the searcher, because it showed up where a real answer should be. A site that closes a warm prospect is credible because it did its job. Treat credibility as a fourth pillar you're separately optimizing for, and you get exactly what most under-scoped company sites look like: a homepage with a vague mission statement, a team photo grid, three value-proposition tiles that could belong to any competitor, and no way to know if any of it changed anyone's mind about anything.

The test for whether "credibility" is a legitimate goal or a fig leaf is simple: can you name the person who gets reassured, and the moment it happens? "A prospect three days before a signed contract, checking that the case studies on the page match what the salesperson told them" is a real answer — that's job two, wearing a different name. "A candidate deciding whether to reply to a cold outreach message from our recruiter" is also real — same job, different visitor. "So people take us seriously" with no named person and no named moment is not a job. It's the reason budget gets approved for a project nobody can later say succeeded or failed, because success was never defined.

The sales-enablement site: where traffic is irrelevant and nine pages is correct

Job four deserves its own section because it's the job most consultancies, agencies, and B2B service firms are actually doing, whether they've admitted it or not — and it's the one where the entire logic of "more pages, more traffic, more content" is not just unnecessary but actively wasteful.

Picture a nine-person engineering consultancy that closes six figure contracts through relationships — former colleagues, conference introductions, warm referrals from past clients. Nobody at a company like this is Googling "engineering consultancy near me" and landing on page one of results; that search doesn't reflect how the deal actually starts. The website's real job is what happens after the first conversation: the founder says "I'll send you our site," and thirty seconds later a link lands in the prospect's inbox, and what that prospect sees in the next ninety seconds either confirms what they were just told on the call or quietly contradicts it.

For that job, a nine-page site — home, about, three or four service pages, a handful of case studies, contact — is not a compromise. It's correct, and adding more would actively hurt it. There's no case for a blog updated weekly, because nobody making a six-figure buying decision is subscribing to your RSS feed to be nurtured over months; the entire cycle happens inside a handful of direct conversations, and the site's job in that cycle is to be checked, not browsed. There's no case for dozens of narrow SEO landing pages targeting long-tail search terms, because the traffic those pages might bring in isn't the traffic that becomes a client here — the client was already warm before they typed the URL. Building job-one infrastructure for a job-four company is spending real budget on an audience that was never going to buy.

The tell that a site is actually doing job four, whether anyone planned it that way or not, is where the traffic comes from. Check the referrers. If a large share of sessions arrive as direct traffic or from email and LinkedIn message links rather than search, the site is being sent, not found — and the content, page count, and update cadence should be built for a reader who arrived with context already, not a stranger doing comparison shopping. This is the site that should read like a leave-behind: dense with specific proof — named projects, real numbers where you have them, the actual people who'll be on the account — rather than broad with category-covering pages that a search-driven site would need. We've broken down exactly how many pages that kind of site needs and where the line sits between "enough proof" and "padding" in how many pages a small company website needs.

The job decides the page count, the CMS, and the budget — in that order

Most website projects get these three decisions backwards. Someone picks a CMS first because a developer has a preference or because a template looked good, then the page count gets filled in to justify the platform, then the budget gets set by whatever the agency quoted for that scope. The job that platform and that page count are supposed to serve never enters the conversation, which is exactly how a nine-person consultancy ends up paying for a headless CMS built to support fifty content editors publishing daily, or a search-driven business ends up on a page builder that can't handle programmatic landing pages at scale.

Run the decisions in the other order and each one gets easier, because each one is now answering to something concrete instead of to taste.

The job sets the page count first, because job one and job three both want to expand — more search terms to target, more self-service topics to cover — while job two and job four both want to stay narrow, because every additional page is one more chance to dilute a warm visitor's attention before they take the one action you actually want. A site can't be told "grow the content" and "stay focused" by the same brief; the job decides which instruction applies.

The page count then sets the CMS, not the reverse. A nine-page site updated twice a year does not need a content platform built for a newsroom — it needs something the one person responsible for it can update without filing a ticket. A site adding dozens of pages a quarter, run by a content team, needs exactly the infrastructure the small site doesn't: structured content types, an approval workflow, and a platform that won't buckle when page five hundred goes live. Choosing the CMS before knowing which of these you are is how companies end up either straining a lightweight builder past its limits or paying enterprise rates to maintain a site nobody touches after launch.

And only then does the budget make sense, because now it's buying something specific — content production and technical SEO retained monthly for job one, a focused build with strong proof pages for job four, self-service infrastructure and a support integration for job three — rather than a lump sum for "a new website" that gets spent on design polish because polish is the only thing left to spend it on once the job was never named. We've laid out what each of these actually costs across a realistic three-year window, not just at launch, in what a company website costs over three years, because the build price is rarely where the real spending happens.

The test: take the site down for a week

Here is the cleanest way to find out, for any existing company website, whether it has a real job or just an unexamined one. Imagine it goes offline for a week — server dies, domain lapses, whatever the cause — and ask what specifically stops happening, and how soon someone would notice and complain.

If the honest answer is a support team fielding a spike in calls asking questions the help center used to answer, that's job three, and it's real, because the absence is measurable within hours. If it's a sales team suddenly unable to send the link they always send after a first call, and a prospect emailing back "the site seems to be down, is everything OK," that's job four, and the absence is real too — it shows up as friction in deals already in motion. If it's search traffic and inbound form fills quietly not arriving for a week, visible only in an analytics dashboard nobody checks until month-end, that's job one, doing its job in a way that's real but slow to notice.

But if the honest answer is "probably nothing, someone might mention it looks unprofessional if they happened to visit," the site has never had a job in the sense this piece means. It has had a vibe, and vibes don't survive a serious question about what they cost to maintain versus what they return. That's not a reason to have no website — a company without any site at all raises its own questions, and for many buyers a bare-minimum presence still matters, particularly around how a stranger actually gets in touch, which is its own decision covered in contact form versus booking link versus phone number. It's a reason to stop treating "we need a website" as a complete brief, and start with the harder sentence: which of these four things, specifically, is this one going to do — and for a single-person operation the honest answer is often the narrowest version of job four there is, which is its own case, made in the one-page site a solo consultant needs.

Name the job before the first wireframe. Everything downstream — the page count, the platform, the budget, and eventually the honest verdict on whether the redesign worked — follows from that one decision, and almost nothing else does.