Answer in brief
The points worth carrying forward.
- 01Define page purpose, owner and success signal before development.
- 02Test content, interactions and failure states across real viewport sizes.
- 03Protect URLs, metadata and measurement during redesigns or migrations.
- 04A launch is complete only when monitoring, access and handoff are clear.
Section / 01
1. Strategy and requirements checklist
- Name the primary business objective and no more than a few supporting outcomes.
- Define priority audiences, their context, tasks, objections and accessibility needs.
- Inventory required pages, languages, legal content, integrations and content owners.
- Record the current domain, DNS, hosting, CMS, analytics, Search Console and account ownership.
- Set scope boundaries for ecommerce, bookings, payments, user accounts, uploads and third-party services.
- Define acceptance criteria, approval owners, launch authority and a rollback decision path.
Section / 02
2. Content and information architecture checklist
- Assign one clear purpose and primary audience task to every planned page.
- Map search intent and customer questions without creating near-duplicate keyword pages.
- Use descriptive, stable URLs and record redirects for every changed or removed valuable URL.
- Write unique titles, descriptions, headings and answer-first introductions.
- Place claims beside real evidence and remove placeholders, fake testimonials and unsupported numbers.
- Create crawlable contextual links between related services, guides, locations and conversion pages.
- Prepare descriptive filenames, dimensions, alt text decisions and rights information for media.
Section / 03
3. Responsive UX and accessibility checklist
| Journey | Test | Failure to catch |
|---|---|---|
| Navigation | Keyboard, touch, active state, escape and focus return | Trapped focus, hidden pages, tiny targets |
| Reading | 320px mobile, zoom, long headings and long URLs | Overflow, clipped text, unreadable measure |
| Forms | Labels, required fields, invalid input, errors and success | Silent failure or error messages not associated with fields |
| Media | Missing image, slow image, captions and text alternatives | Layout shift or essential information available only in an image |
| Motion | Reduced-motion preference and paused content | Animation that blocks or disorients |
| Contrast | Text, controls, focus and disabled states | Low-contrast information or colour-only meaning |
Section / 04
4. Development checklist
- Use semantic HTML before adding ARIA and keep heading order meaningful.
- Build reusable components with typed inputs and explicit empty, loading, success and error states.
- Keep client-side JavaScript limited to interactions that need it.
- Reserve image dimensions, serve responsive sizes and optimise formats without destroying quality.
- Prevent secrets, private keys and environment-specific credentials from entering client bundles or version control.
- Validate and sanitise untrusted input on the server when forms or APIs exist.
- Handle not-found routes, unexpected data and third-party service failure honestly.
Section / 05
5. Technical SEO and performance checklist
- Return an appropriate 200, redirect, 404 or error response; do not serve every missing page as success.
- Confirm canonical URLs, robots directives, sitemap inclusion and crawlable internal links.
- Keep important rendered text and links available to search crawlers without requiring hidden interactions.
- Add structured data only when it matches visible content and a specific applicable type.
- Check LCP, INP and CLS with lab and field data where available; investigate causes rather than chasing a score alone.
- Test metadata and social-sharing previews for each public page type.
- For migrations, preserve valuable URLs or map one-to-one permanent redirects and monitor errors after launch.
Section / 06
6. Measurement, privacy and security checklist
- Create an event plan from business questions before installing tags.
- Verify each key event once in the intended journey and prevent duplicate firing.
- Exclude sensitive content and personal data from analytics parameters.
- Document cookies, storage, embeds, processors and consent behaviour accurately.
- Use HTTPS, current dependencies, least-privilege account access and multifactor authentication where available.
- Define backups, restore ownership, incident contacts and dependency-update responsibility.
- Run security review proportional to risk; brochure sites and payment or account systems do not share the same threat model.
Section / 07
7. Launch-day checklist
- 01
Freeze and verify the candidate
Build the exact release, record the commit and confirm production environment variables and integrations.
- 02
Run route and link checks
Test priority URLs, redirects, navigation, downloads, contact channels, forms and external destinations.
- 03
Inspect three responsive widths
At minimum check a small mobile, tablet and large desktop, then test orientation, zoom and real devices where available.
- 04
Validate search controls
Review titles, canonicals, indexability, robots, sitemap, structured data and status codes on the production host.
- 05
Validate measurement and consent
Confirm tags respect the documented consent state and key actions record once with no personal data.
- 06
Change traffic carefully
When DNS or routing changes are needed, confirm the exact records, SSL state and rollback path before mutation.
- 07
Monitor
Watch availability, errors, real journeys, indexing reports and analytics anomalies after launch.
Section / 08
8. Handoff checklist
- Repository, hosting, DNS and analytics ownership transferred to named people
- Setup, build, deployment and rollback instructions tested by someone other than the author
- Environment variables documented without exposing values
- Content editing and media guidelines recorded
- Licences, third-party terms and renewal dates listed
- Known limitations, deferred work and risk accepted explicitly
- Post-launch support scope, response expectations and maintenance owner agreed
Sources and maintenance
Primary references behind this guide.
Written by Rohan Neure. Published August 25, 2026 and last reviewed August 26, 2026. Product interfaces and policies can change; the linked first-party sources are the current reference points.
- 01SEO Starter Guide ↗Primary source
Google Search Central · URLs, links, metadata, crawl access and useful content
- 02Web Vitals ↗Primary source
web.dev / Google · LCP, INP and CLS performance checks
- 03Web Content Accessibility Guidelines 2.2 ↗Primary source
W3C · Accessibility requirements
- 04OWASP Application Security Verification Standard ↗Primary source
OWASP · Risk-based web application security reference
Related decisions
Continue with the closest useful path.
Questions answered
Frequently asked questions.
01When should the website checklist begin?
Before design. Requirements, content ownership, URLs, integrations and launch authority affect every later decision.
02What should be tested after deployment?
Test status codes, navigation, contact actions, forms, redirects, metadata, structured data, measurement, consent, responsive layouts, keyboard journeys and production console errors.
03Is an automated accessibility score enough?
No. Automated tools find only some issues. Manual keyboard, zoom, screen-reader-informed and task-based testing remains necessary.
04Should every page be in the XML sitemap?
Include canonical public URLs you want search engines to consider. Utility, duplicate, private or intentionally non-indexed URLs usually do not belong.
05Do simple websites need security work?
Yes, although risk differs. Protect accounts and dependencies, use HTTPS, avoid exposing secrets and maintain a recovery path.
Use the guide
Planning a website build or migration?
Send the scope, current URL and launch constraint. GrowthLabs will map the information, SEO, conversion and measurement requirements before build risk grows.
No form on this site. Contact GrowthLabs directly by email, phone or WhatsApp.