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. Ongoing website care should include form monitoring and a known fallback contact—not merely checking that the homepage still loads.

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.

Maintenance includes discovery, not just 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)

Useful ongoing care 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.

That is maintenance of the website as a business system, not just maintenance of a server.

A website can be a first project without being an AI prerequisite

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.

Richardson Applied AI offers two independent starting points. If the public front door needs work, the website can be the first project. If the website is already strong—or the internal opportunity is simply more important—we can start directly with the systems, processes, and knowledge work inside the business.

Neither path is a gate for the other.

What Richardson Applied AI includes for $1,500

The Richardson Applied AI website offer is a complete build around an approved sitemap and content plan, not a five-page starter package.

The $1,500 project includes research-backed commercial and educational content, the agreed page structure, mobile-first implementation, ordinary content and media migration, preserved URLs or explicit redirects, forms, metadata, canonical URLs, structured data, a sitemap, a private preview, and two revision rounds. The approved sitemap may be small or extensive; the boundary is the content plan agreed at kickoff.

Managed care is $99 per month and includes hosting and SSL administration, uptime and form monitoring, deployment maintenance and rollback, two minor content edits per month, and ongoing sitemap, discovery, Search Console, Bing Webmaster Tools, and IndexNow upkeep. New researched sections, application features, e-commerce, portals, databases, and major redesigns are separately scoped.

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.