Hardly anyone lands on a company website by accident. They got a referral, saw the company's name on a proposal, searched for it on Google or asked an AI assistant who offers that service nearby. They arrive to confirm: does this company exist, does it do what it says, and is it easy to reach?

That's why I treat a company website as a reference document, not a brochure. It doesn't need to impress in five seconds; it needs to answer well the questions someone asks before trusting you. In this post I explain how I think about that structure when I design and build this kind of site.

A company website is not a landing page

The most common mix-up is trying to do both on a single page. A landing page has one offer and one goal. A company website presents the whole business and has to serve visitors with different intentions.

Landing pageCompany website
GoalOne action on one offerPresent the company and its services
Who visitsSomeone coming from a campaign or a specific searchClients, partners, suppliers, job candidates
StructureOne page, one pathSeveral pages, clear navigation
Typical timeline with me5 to 10 business days2 to 4 weeks

If what you need right now is to convert a campaign, the post on landing pages that convert will be more useful. From here on, I'm talking about the site that represents the company.

The pages almost every company needs

There's no right number of pages, but there is a minimum set of questions. Each page answers one of them.

  • Home: what the company does, for whom and where, in one or two sentences, no slogan. Right below, the main paths: services, work, contact.
  • Services: one page per service when they serve different audiences or problems. This is usually where the decision to get in touch happens, which is why I wrote a whole post about it: a services page that brings in inquiries.
  • About: who is behind it, for how long, how they work. People hire people. A real photo and an honest paragraph do more than a generic mission, vision and values block.
  • Projects or case studies: what was done, for what kind of client, what the problem was. Context is worth more than a wall of logos.
  • Contact: channels someone actually answers, and what to expect after sending a message.

A blog or content area makes sense when there's something to say on a regular basis. It changes the scope — a site with a blog usually takes 4 to 6 weeks — and it's only worth it if someone will keep feeding it afterwards.

Trust signals that don't depend on design

Good design helps, but trust comes mostly from verifiable information. Before thinking about visual effects, check that the site shows:

  • the legal company name and registration number, when that makes sense for the type of business;
  • the city and the area you serve, spelled out;
  • phone, email and WhatsApp matching the ones on your Google profile, social media and documents;
  • real photos of the work, the people or the space, instead of stock images;
  • visible dates on content that ages, such as news and articles.

The opposite holds too. Numbers nobody can verify, anonymous testimonials and "market leader" claims without context weaken the rest of the page, and someone who came to confirm will notice. How to write all of this without empty phrases is covered in copy for service websites.

The technical foundation nobody sees

A company website is read by people and by machines. Search engines and AI assistants need to understand the same things a visitor does: who the company is, what it offers, where it operates. That's why the invisible part matters as much as the visible one:

  • a unique title and description on every page;
  • a heading hierarchy that makes sense when read in order;
  • a correct sitemap.xml and robots.txt;
  • organization structured data (schema.org Organization) with name, logo, official site and profiles;
  • fast pages that read well on a phone, which is where many people will open the link you sent them by message.

These days I also include a layer designed for AI agents, with llms.txt and markdown versions of the main pages. The full list of what I check is in the checklist for an agent-ready site.

Who owns what

This question usually comes up only when something goes wrong: the provider disappeared, the domain expired under someone else's name, nobody knows the hosting password. It's worth settling before you start.

In the projects I do, domain, hosting, code repository and credentials stay in the client company's name, with the access documented. Content lives in a simple CMS or in files I show you how to edit, depending on the project. That way, changing a phone number or publishing a new page doesn't depend on me, and bigger changes are still possible when they make sense.

If you're evaluating any provider, ask this in writing. The answer says a lot about how the project will be run.

Where to start

Before thinking about layout, write short answers to five questions: what the company does, for whom, where, which services it offers and how someone gets in touch. If any answer is slow to come, that's where the site will need the most work — and it's a great starting point for a brief.

If you like, send me those answers through the contact page and I'll reply with the questions that are still missing.

References