What a Modern Business Website Should Actually Do

Most website proposals begin with a page count and a new look. Neither tells you whether the finished website will be useful.

A modern business website has a larger job. It should explain the business well enough for a serious buyer to understand it, make it easy for that buyer to take the next step, preserve the useful history the current site has earned, and remain healthy after launch. The design matters, but design is the container. The real product is a working body of information and a dependable path from interest to action.

That is what a modern business website should actually do.

A website is not a five-page brochure

Home, About, Services, Contact, and a privacy page may be the core of a simple sitemap. They are not a universal definition of a complete website.

A manufacturer may need separate pages for capabilities, industries, materials, quality standards, certifications, equipment, applications, and its quote process. A professional service company may need detailed pages for each engagement, the problems it solves, the people who do the work, and the questions clients ask before hiring. A company with several product categories may need a clear information architecture before a buyer can even find the right starting point.

The correct page count is the result of the content plan. It should not be an arbitrary sales boundary chosen before anyone has learned the business.

That does not mean publishing dozens of thin pages. Google explicitly recommends creating helpful, reliable, people-first content that gives an audience substantial, complete information—not mass-producing pages simply to attract search visits. Its own self-assessment asks whether a page provides original value, demonstrates real knowledge, and leaves the reader feeling that they learned enough to accomplish their goal. (Google Search Central: helpful, reliable, people-first content)

The goal is depth where depth is useful.

The content should answer the buyer's real questions

Good website research begins with the questions a qualified buyer would ask a knowledgeable person at the company.

• What exactly do you do?
• Who is it for—and who is it not for?
• What capabilities, materials, systems, or standards matter?
• How does the process work from first conversation to delivery?
• What information do you need before you can quote or recommend anything?
• What happens when the normal job becomes unusual?

Those answers often belong on dedicated service, capability, industry, product, standards, and educational pages. The commercial pages explain what the company offers. The educational pages help a buyer understand the decision around it. Internal links connect the two, so useful information does not become an isolated pile of blog posts.

Research can find gaps and organize the material. AI can accelerate drafting and production. Neither one gets to invent company facts. Technical claims, certifications, customer promises, and descriptions of the real process still need sources and owner review.

Deep content is not valuable because it is long. It is valuable because it removes uncertainty for the right person.

Forms must work and stay working

A contact or quote form is not decoration. It is part of the company's intake system.

When a buyer submits it, several things must happen correctly: the browser should accept the information, the server should validate it, the message should reach the intended destination, and the buyer should see a clear confirmation. If files are allowed, those files need a safe destination. If the delivery service fails, someone needs a way to notice.

Testing a form on launch day is necessary. It is not enough. Dependencies change, inbox rules change, credentials expire, and deployments can break behavior that looked fine in a preview. Whoever keeps the site current needs a way to confirm the form still delivers, such as a test submission after every change, and the site needs a fallback contact that works when the form does not. A homepage that still loads says nothing about the form.

This is one reason the least expensive website is not always the one with the smallest invoice. A beautiful site that quietly loses serious inquiries is expensive in the only way that matters.

Migration should preserve what search engines already know

A rebuild creates risk when it treats the old site as disposable.

Before changing anything, inventory the current URLs. Decide which pages will stay, which will be combined, which will be replaced, and which are no longer useful. Keep a valuable URL when there is no reason to change it. When a URL must move, map the old address to the most relevant new address with a permanent server-side redirect.

Google's site-move guidance calls for preparing the new site, testing it thoroughly, creating an old-to-new URL map, and configuring redirects. Google also notes that it must revisit old and new URLs during the move, so changes can take time to settle. (Google Search Central: site moves and migrations)

The practical rule is simple: migration is a mapping exercise, not a copy-and-paste exercise.

Search engines and answer engines need clear structure

Useful human-readable content comes first. Technical structure helps machines understand and discover it.

Each indexable page should have one canonical address, a descriptive title, a useful summary, and internal links that reflect how the topics relate. Structured data can give search engines explicit clues about the organization, article, service, breadcrumb trail, video, or FAQ described on the page. Google recommends complete and accurate markup that matches visible page content and makes clear that correct markup does not guarantee a rich result. (Google Search Central: introduction to structured data, structured-data guidelines)

The same discipline helps answer systems. Clear entities, direct explanations, useful headings, source-backed claims, and consistent relationships are easier for both people and machines to interpret. Files such as llms.txt and llms-full.txt are still proposed discovery patterns, not a replacement for a good website, but they are inexpensive to maintain when generated from the same canonical content inventory.

No one can responsibly promise that a search engine or AI system will include a page. The part a website owner controls is making the information accurate, accessible, structured, and worth finding.

Upkeep includes discovery as well as uptime

Publishing is an event. Discovery is a continuing process.

An XML sitemap should contain the canonical URLs the site wants search engines to find. Google recommends absolute canonical URLs and explains that a sitemap submission is a hint, not a guarantee of crawling or indexing. Search Console shows whether Google processed the sitemap and helps inspect important individual URLs. (Google Search Central: build and submit a sitemap)

Bing Webmaster Tools also accepts sitemaps and reports their processing state. For material additions, updates, and removals, IndexNow can automatically notify participating search engines; an accepted response means the notification was received, not that the page is now indexed. (Bing Webmaster Tools: sitemaps, IndexNow documentation)

Keeping a site healthy after launch therefore includes:

• uptime, SSL, deployment, and rollback health;
• form-delivery monitoring;
• current canonical metadata and structured data;
• sitemap and discovery-file generation from the real page inventory;
• Search Console and Bing Webmaster Tools review;
• IndexNow notification when URLs materially change; and
• a clear record of what was published and when.

Uptime and SSL come from the hosting provider, in the owner's own account. A good setup builds most of the rest into the site itself. The structured data, the sitemap, and the discovery files come from the real page inventory each time the site publishes, a build check stops a page that is missing its structure, and the repository keeps the record of what was published and when. What is left is a short routine for whoever keeps the site current: send a test through the forms after a change, and look at Search Console and Bing Webmaster Tools every so often.

A website is never a prerequisite for AI work

Website work often reveals how information moves through a company. Building a service page can expose an unclear handoff. Rebuilding a quote form can uncover a manual intake process behind it. Organizing standards and product information can reveal knowledge that lives in one person's head.

Those observations can be useful. They do not turn a website project into an AI audit, and they do not mean every company needs a new website before it can work on internal systems.

At Richardson Applied AI, a website is an optional project of its own, and a site that already does its job gets left alone. When a company does both, the people on its team who own the AI work, the ones we call Champions, usually keep the website current too. The site runs from written instructions and one facts file, much like their Operating Standard, so updating it is part of work they already do instead of a separate project someone else manages.

What Richardson Applied AI builds and hands off

We build the site, train your people, and hand it over. The build follows an approved sitemap and content plan with no page cap, plus any functionality we agree to build, such as quote requests with the drawings attached, maintenance and service requests, a product catalog, or a library of spec sheets and certifications. It includes research-backed commercial and educational content, mobile-first pages, ordinary content and media migration, preserved URLs or explicit redirects, forms, metadata, canonical URLs, structured data, a sitemap, a private preview, and revision rounds.

You own and control all of it from the start. The domain, the hosting account, and the repository with the site's code sit in your company's own accounts, your people hold the admin and billing access, and we work through access you grant instead of your passwords. When the handoff is done, we remove our access to publish.

We build the site so someone on your team can keep it current without paying anyone to do it. The repository carries written instructions an AI assistant follows, your company facts live in one file, page templates write the structured data, and a check on every build stops a page that is missing its required structure. Before the handoff we train the people who will run it, usually the same Champions who own your AI work, and the handoff is done when one of them has made a real change from start to finish. After that the site is yours to run. When you want new functionality later, like a customer login or a scheduling tool, we scope it as a new project.

Every build is scoped and quoted in writing against what the site needs, since a focused rebuild and a full technical content library are different jobs. The free written read comes first, and the quote comes after it.

If you want an outside-in view before deciding anything, request a free written website read. If your website is already doing its job and you want to look directly at the operation, start with the applied AI path.