What a website project should include: a plain checklist

Why a checklist

Two proposals arrive. Both have handsome mockups. One page each on design, one line each on everything else. They look the same.

A year later they don't. One site loads quickly, its forms reach the right people and the company owns every account. The other runs on the agency's hosting, under the agency's analytics login, and nobody knows why inquiries dropped in March.

The difference was in the lines nobody read. Here they are, in plain words.

1. Ownership

Start here, because everything else depends on it.

• Domain. Registered to your company, with a company email address as the contact. Not a person, not the agency.
• Hosting. In an account your company owns and pays for, or with a clear way to move it to one.
• Analytics and search tools. Google Analytics or your chosen tool, Search Console and Bing Webmaster Tools, all owned by your company.
• Code and content. Yours, in writing, with access to the source.
• Every other account. Forms, email sending, scheduling, fonts, any paid service the site uses.

Write the list down in one place, with who owns each account, who can log in and when anything renews. It takes an hour, and it turns a future emergency into a routine task. Keep it somewhere the whole leadership team can find it, not in one person's inbox.

Ask one question of any proposal: if we parted ways tomorrow, what would we still have, and what would we have to rebuild?

2. Speed

Speed is not a feeling. Google publishes three Core Web Vitals, explained on web.dev, with clear thresholds for a good experience:

• Largest Contentful Paint, how fast the main content appears: within 2.5 seconds.
• Interaction to Next Paint, how quickly the page responds to a tap or click: 200 milliseconds or less.
• Cumulative Layout Shift, how much the page jumps around while loading: 0.1 or less.

web.dev recommends measuring at the 75th percentile of real page loads, on mobile and desktop separately. That matters. A site that is fast on the designer's laptop can be slow on a field manager's phone.

Ask how the proposal will measure speed after launch, not just at handover. Google's free PageSpeed tools report real-visit data where a site has enough traffic.

3. Accessibility

An accessible site can be used by people with disabilities: with a keyboard instead of a mouse, with a screen reader, with zoomed text, with color blindness. It also tends to be easier for everyone.

The reference is the W3C's Web Content Accessibility Guidelines. WCAG 2.2 became a W3C Recommendation in October 2023, and the W3C encourages using the latest version. Content that meets 2.2 also meets 2.1 and 2.0. Most organizations aim for level AA.

In plain terms, that covers things like readable color contrast, text alternatives for images, forms with proper labels and error messages, and everything usable with a keyboard. WCAG 2.2 added criteria on focus visibility, target sizes and not making people re-enter information.

Ask who will check it, how, and whether real assistive technology is part of the testing. If you have specific legal obligations, confirm them with your counsel.

4. Analytics and consent

You should be able to answer one question from your analytics: which pages bring in inquiries?

• Track form submissions as events, so you can see where inquiries start.
• Keep the setup simple enough that someone on your team can read it.
• Decide what consent you need based on where your visitors are and what you collect. That is a question for your counsel, not your designer, but the site has to be built to support the answer.
• Describe what you collect in a privacy policy that matches what the site actually does.

5. Structured data

Structured data labels your pages in a format search engines read: your organization, your articles, your questions and answers. Google says it helps it understand pages and can make them eligible for richer results, without guaranteeing them.

The rule that matters most: the markup has to match what visitors can see. Ask how it will be kept in sync when pages change, and how it will be checked.

6. Redirects

If any address changes, every old address needs a permanent redirect to its true match. Google's site move guidance recommends keeping redirects for at least a year, pointing each straight at its final destination and not sending everything to the homepage.

Ask for the redirect map as a deliverable. It should exist before launch, not after the inquiries drop.

7. Forms and where they go

This is the line that most often gets one sentence in a proposal and costs the most when it's wrong.

• Where does each form's submission go: an inbox, your CRM, both?
• Who owns each inquiry, and what happens if they're away?
• What does the visitor see and receive after submitting?
• How is spam filtered, and who checks what the filter caught?
• How will you know if a form stops working?

A weekly test submission, followed all the way to a person, is the cheapest safeguard on the site.

8. Security

A marketing site doesn't hold your crown jewels, but it carries your name. The basics are well documented:

• HTTPS everywhere, with plain HTTP redirected.
• Security headers that tell browsers how to treat your pages. The OWASP cheat sheet on HTTP headers and MDN's guide to Content Security Policy are good references.
• Sign-in to every account protected by more than a password.
• Plugins and dependencies kept up to date, or kept to a minimum.
• Access removed when people leave.

If larger clients send you security questionnaires, the website will come up. It helps to have the answers written down.

9. Search setup

A new site can launch looking perfect and stay invisible. The usual causes are small and easy to check.

• A noindex tag or a password left over from the staging site.
• A robots.txt file that blocks crawlers you meant to allow, including the ones that feed AI answers.
• A sitemap that lists old addresses, or is missing.
• Search Console and Bing Webmaster Tools not set up, so nobody sees the errors.
• Titles and descriptions copied across pages, so each page looks like the others.

Ask for these to be on the launch checklist, and checked again a week later.

10. Who maintains it

Every site needs an owner after launch. Someone who updates pages, renews the domain, watches the forms, applies updates and notices when something breaks.

Ask the proposal to say who that is, what they'll do each month and how your team can make everyday edits without them.

Be specific about the everyday edits. Changing a phone number, adding a team member, posting a new article or updating a service description should not need a developer. Larger changes, like a new section or a new form connected to your systems, usually should. Agree where that line sits before launch, so nobody is surprised by a request that takes a week.

Questions to ask any proposal

1. Which accounts will be in our name, and which in yours?
2. How will you measure speed and accessibility, and when?
3. Where does each form go, and how will we know if one breaks?
4. Will you deliver a redirect map before launch?
5. Who writes the content, and who checks the facts?
6. What happens in the first month after launch, and after that?

A good answer to each is short and specific. A vague one is worth a follow-up question.

What most guides miss

The domain renewal is a single point of failure. When a renewal notice goes to a former employee's inbox, the whole site can go dark. Put renewals on auto-renew, with a company card and a shared address.

Content is usually the long pole. Design and build often finish before the words do. Plan who writes and approves each page from the start.

Ask to see the launch checklist. A team that has done this before will have one. Its absence tells you something.

Measure after launch, not just at it. Speed, accessibility and forms all drift as pages and plugins are added. A new tracking script here, a large image there, and a fast site becomes a slow one without anyone deciding it should. Put a quarterly check on the calendar.

How we do it

We start with a free intro call, and every item on this list is part of how we build. We work alongside your team: domain and accounts in your name, speed and accessibility checked, forms connected to your systems, and a clear owner after launch. See websites and content for more.

Sources

1. web.dev: Web Vitals
2. W3C: Web Content Accessibility Guidelines (WCAG) 2.2
3. W3C Web Accessibility Initiative: WCAG 2 overview
4. W3C Web Accessibility Initiative: What's new in WCAG 2.2
5. Google Search Central: Introduction to structured data markup
6. Google Search Central: Site moves with URL changes
7. OWASP: HTTP security response headers cheat sheet
8. MDN Web Docs: Content Security Policy