Playbook · Enterprise web

The enterprisewebsite checklist.

Not a feature list. These are the 40 things that decide whether an enterprise site still works two years after launch — when the launch team has moved on and four departments are publishing into it every week.

Scaffolding braced against a graphic grid — the structure behind the surface

Enterprise websites rarely fail loudly. They launch well, get praised for a quarter, and then degrade one entirely reasonable decision at a time — a new template here, an unowned section there, a tracking script somebody needed for a campaign in 2023. Two years later everyone agrees the site is a problem and nobody can point to the moment it became one.

So this list is deliberately weighted away from the things that get argued about in the pitch. Very little of it is about visual design, and none of it is about which CMS won the evaluation. The checks that predict the outcome are duller than that: who owns what, what gets published, what happens when it is wrong, and whether anyone is funded to care after launch.

Use it as a diagnostic. Go through it honestly, mark the ones you would fail today, and look at where the failures cluster. That cluster is your real project — and it is often smaller and cheaper than the redesign you were about to commission.

Go through it honestly

01

Ownership and governance

The category that quietly decides everything else. Sites do not decay because the design was wrong; they decay because nobody was accountable for keeping it right.

  • One named person owns the experience end to end.

    Not a committee, not a steering group. When six departments each own a piece, the seams between them belong to nobody — and the seams are where customers actually get lost.

  • There is a written decision path for “can we add this?”

    Every enterprise site is one unrefused request away from a new template. Without a documented answer, the loudest stakeholder becomes the information architecture.

  • Publishing rights are scoped, and someone reviews before release.

    Either everyone can publish anything or nothing ships for six weeks. Both are governance failures. The workable middle is scoped rights with a light, fast review.

  • Content has named owners with review dates, per section.

    Unowned content is never wrong enough to fix and never right enough to trust. A named owner and a date turn “someone should update this” into a task with an address.

  • There is a budget line for the site after launch.

    A site funded as a project and maintained as a favour will look exactly two years old, permanently. Ongoing investment is the difference between a platform and a monument.

02

Audience and content

Most enterprise sites are organized around what the company wants to say, then patched with navigation to help people find what they came for.

  • You can name the top five tasks people come to do.

    Not personas — tasks. If the five things that account for most of your traffic are not obvious within one click, the site is arranged for the org chart rather than the visitor.

  • Every page has a reason to exist that someone can state out loud.

    The average enterprise migration carries thousands of pages nobody has opened in a year. Each one dilutes search, adds review burden, and hides the pages that matter.

  • Content is written for the reader, not for the approval chain.

    Copy that survives six rounds of internal review tends to say nothing that could be disagreed with, which is the same as saying nothing.

  • Product, pricing and technical claims have a single source of truth.

    When the same number lives on four pages, three of them will be wrong within a quarter — and the sales team will find out from a customer.

  • You have a real plan for the content nobody wants to migrate.

    “We will sort it during the build” means it gets migrated verbatim at 2am in launch week. Decide what dies before the schedule decides for you.

03

Structure and navigation

Information architecture is the part users experience as “this site is easy” — and the part that is most expensive to change after launch.

  • Navigation reflects how people think, not how you are organized.

    Customers do not know which business unit owns the thing they need, and they should never have to guess. Internal structure leaking into the menu is the most common enterprise IA failure.

  • The structure has been tested with people outside the company.

    A tree test with twenty strangers costs almost nothing and routinely overturns months of internal debate. Everyone inside already knows where things are, which makes them useless as a test.

  • Search works, and someone reads what people searched for.

    Site search logs are the cheapest research in the building — an unfiltered list of what people wanted and could not find. Almost nobody reads them.

  • URLs are stable, and redirects are planned before launch.

    A redesign that drops link equity can cost more traffic than the redesign wins. Map old to new while it is still a spreadsheet, not an emergency.

  • Every page tells you where you are and what is nearby.

    Most visitors arrive from search, deep in the site, with no context. If a page only makes sense to someone who came via the homepage, most of your audience will never make sense of it.

04

Design system and brand

The site will be edited by dozens of people for years. What holds quality is the system, not the taste of whoever is editing today.

  • Components exist that authors cannot break.

    If a page can be assembled badly, it eventually will be. The constraint is the feature: good components make the correct layout the easiest one to build.

  • Design tokens are shared between design and code.

    When a colour or spacing value lives in two places, they diverge within a release. One source keeps the brand honest without anyone policing it.

  • There is a defined set of page types — and adding one is a decision.

    Template sprawl is how sites become unmaintainable. Ten well-made types beat forty bespoke pages every time, including for the people requesting the bespoke pages.

  • The system covers the ugly states, not just the pretty ones.

    Empty, loading, error, too-long-a-headline, no-image, twelve-items-in-a-three-item-slot. Real content is messy, and the messy states are what visitors actually see.

  • Brand expression survives the CMS.

    A distinctive design that flattens into a generic grid the moment real authors touch it was never a design system. It was a set of pictures.

05

Performance

Speed is not a technical nicety on an enterprise site. It is the first impression, and on mobile it is the entire impression.

  • Core Web Vitals pass on real user data, not just in the lab.

    Lab scores are run on fast machines with warm caches. Field data tells you what your actual visitors on actual devices experienced, which is the only number that affects behaviour or rankings.

  • Images are sized, modern-format, and never larger than displayed.

    The single most common performance failure in enterprise CMSes: a 4MB press photo dropped into a 400px slot by someone with no way to know better.

  • You know every third-party script on the page and why it is there.

    Tag managers accumulate. Most enterprise sites carry scripts nobody can attribute, each one costing main-thread time on every visit forever.

  • Layout does not shift while loading.

    Content jumping under a thumb is the most viscerally annoying thing a site can do, and it is almost always fixable by reserving space for media and embeds.

  • There is a performance budget, and builds fail when it is exceeded.

    Performance achieved once is performance lost by the third release. Only automation holds a line that every new feature has an incentive to cross.

06

Accessibility

For most enterprises this is a legal exposure and a procurement requirement, not a value statement. It is also just how you avoid excluding people.

  • You have tested with a keyboard alone, and with a screen reader.

    Automated tools catch perhaps a third of real issues. Ten minutes of tabbing through your top task will find things no scanner reports.

  • Colour contrast passes at real sizes, including on brand colours.

    This is where brand palettes usually break. Better to solve it once in the design system than to lose the argument on every page for the next five years.

  • Focus is always visible and never trapped.

    Custom modals, menus and carousels are where keyboard users get stranded. If focus disappears, so does the ability to use the site at all.

  • Authors cannot publish an image without alt text or a heading out of order.

    Accessibility maintained by goodwill degrades immediately. Put it in the tooling, where it holds without anyone remembering.

  • There is an accessibility statement, and it is true.

    A published statement with known gaps and a remediation date is credible. A boilerplate claim of full compliance on a site that fails basic checks is a liability.

07

Platform and engineering

The platform choice is usually made early, by the fewest people, with the longest consequences.

  • The CMS was chosen for how your team publishes, not for its feature matrix.

    Every enterprise CMS can do everything on the sheet. The difference is whether a marketer can publish a page on Friday without a developer, and that is not on the sheet.

  • Content is structured, not stored as pasted rich text.

    Structured content can be reused, syndicated, translated and redesigned. A wall of HTML in a body field has to be redone by hand every time anything changes.

  • Environments, version control and rollback actually exist.

    Editing production directly is common in enterprise web, right up until the day it is catastrophic. Rollback is worth more than any feature on the roadmap.

  • Integrations degrade gracefully when the other system is down.

    Your site will outlive at least one of the services it depends on. A search outage should not take the homepage with it.

  • Security, privacy and consent are handled at the platform level.

    Per-page compliance is not compliance. Headers, cookie handling and data retention need to be defaults nobody can opt out of by accident.

08

Measurement and life after launch

Launch is the start of the useful part. Most organizations staff it as the end.

  • You agreed what success means before the build started.

    Metrics chosen afterwards are chosen to flatter. Written down first, they tell you whether the investment worked and what to fix next.

  • Analytics track the tasks, not just the pageviews.

    Traffic is not an outcome. Whether someone found the spec sheet, requested the quote, or completed the application is the thing worth measuring.

  • Someone reviews the numbers on a schedule, with authority to act.

    A dashboard nobody owns is decoration. The value is in the standing thirty minutes where a person can decide to change something.

  • There is a roadmap for the twelve months after launch.

    The gap between launch and the next funded initiative is where sites rot. A modest, funded backlog beats a heroic replatform every four years.

  • You are set up to run small experiments, not just big projects.

    The enterprises whose sites keep improving are the ones that can ship a change in a week. Everyone else waits for the next redesign to fix what they learned in month two.

How to read your score

The count matters less than the distribution. Failing eight checks spread evenly across the categories describes a site that needs maintenance. Failing four checks, all of them in ownership and governance, describes an organization that will produce the same site again — better looking, same trajectory.

If the failures cluster in performance, accessibility or engineering, you have a technical remediation project, and it is usually shorter and far less disruptive than a rebuild. If they cluster in content and structure, you have a strategy and governance project wearing a redesign costume. Buying the wrong one of those two is the most expensive mistake in enterprise web.

And if you cannot answer a check at all — nobody knows who owns that section, nobody can say what the top tasks are — that is not a neutral result. An unanswerable question is a failed one, and it is where we would start.

What an audit adds

  • Every check scored against your live site, with evidence rather than opinion
  • Field performance and accessibility results, not lab scores
  • A content inventory that names what should be kept, merged, or retired
  • The governance gaps written down in language leadership can act on
  • A sequenced plan separating urgent, valuable and cosmetic
  • An honest verdict on whether you need a rebuild at all

Who it's for

  • Marketing and digital leaders inheriting a site they did not commission
  • Teams about to write a redesign brief and unsure what belongs in it
  • Organizations where four departments publish and none owns the outcome
  • Anyone holding a replatform proposal that feels larger than the problem
  • Enterprises facing an accessibility or procurement requirement with a deadline

Questions we get

Do we need to pass all forty before we start a redesign?
No — almost nobody does, and a site that passed all forty would not need a redesign. The list is a diagnostic, not a gate. What matters is which ones you fail: failures in ownership, governance and content are the ones that will sabotage a build no matter how good the design is, so fix those first or design around them deliberately.
Which section causes the most damage in practice?
Ownership and governance, by a wide margin. Performance, accessibility and design quality are all solvable with money and skill. A site with no single owner regresses on all three within a year of launch, because every individually reasonable request compounds and nobody is empowered to say no.
We are on a modern platform already. Does that cover most of this?
It covers a slice of the engineering section and none of the rest. A modern platform makes good outcomes possible; it does not make them happen. We have seen genuinely excellent stacks running sites that fail thirty of these checks, because the platform was treated as the strategy.
Can you run this against our current site?
Yes — that is our experience audit. We score every item with evidence attached, separate what is urgent from what is merely untidy, and give you a sequenced remediation plan. It usually takes two to three weeks depending on the size of the estate, and it frequently establishes that a full rebuild is not the right answer.
How often should we run through it?
Once a year is plenty for a stable site, plus once before any significant redesign or replatform. The checks that drift fastest are content ownership, third-party scripts and performance budgets, so those are worth a quarterly glance even when nothing else changes.

Want this run against your actual site?

We'll score all forty with evidence attached, separate the urgent from the untidy, and give you a sequenced plan — including when the honest answer is that you don't need a rebuild.

Book a Strategy Session