Website Development Checklist (Free, Printable)

This checklist walks you through building a website from first plan to live launch. It is written for students and junior developers working with HTML, CSS, JavaScript, PHP and MySQL, and for freelancers who want a repeatable quality check before handing a site to a client. Work through it section by section during the build, then run the whole list again on the staging site before you go live.

0 of 66 checked

Planning

Write down the site's goal, audience and main calls to actionA one-page brief stops scope creep and tells you what each page must achieve.
List every page and draw a simple sitemapAgree the navigation and URL structure before design starts; changing URLs later means redirects.
Collect content, images and brand assets earlyMissing copy is the most common cause of launch delays. Confirm you have rights to every image and font.
Choose the stack and hostingCheck the host supports your PHP and MySQL versions, HTTPS, backups and SSH or SFTP access.
Register the domain and plan DNSKeep domain registrar logins with the client, not just the developer.
Set up version control from day oneCreate a Git repository and commit small, described changes. Never commit passwords or API keys.
Agree browsers and devices you will supportUsually the current versions of Chrome, Edge, Firefox and Safari, plus Android and iOS phones.

HTML, semantics and accessibility

CSS and responsive layout

Add the viewport meta tag to every page<meta name="viewport" content="width=device-width, initial-scale=1"> makes mobile browsers use the device width.
Build mobile-first with min-width media queriesStart with the small-screen layout and add complexity as space grows.
Use Flexbox and Grid instead of floats for layoutThey are supported in all modern browsers and make responsive layouts simpler.
Use relative units for type and spacingrem for font sizes respects the user's browser settings; avoid fixing heights on text containers.
Check there is no horizontal scrolling at 320px wideOverflowing tables, long URLs and fixed-width elements are the usual causes.
Respect prefers-reduced-motionTurn off or reduce non-essential animation for users who request it.
Remove unused CSS and keep one consistent set of stylesUse custom properties (CSS variables) for colours and spacing so changes happen in one place.

JavaScript

Make core content and navigation work without JavaScript where practicalProgressive enhancement keeps the site usable if a script fails to load.
Load scripts with defer or type="module"This stops scripts from blocking HTML parsing.
Check the browser console for errors on every pageOpen DevTools and fix all errors and warnings before launch.
Never trust client-side validation aloneValidate again on the server; JavaScript checks are for convenience only.
Use textContent rather than innerHTML for user dataInserting untrusted strings as HTML creates cross-site scripting (XSS) risks.
Keep third-party scripts to a minimumEach tag, widget or tracker adds weight and a security dependency. Remove ones nobody uses.
Manage focus in modals and dynamic contentMove focus into an opened dialog, trap it there and return it when the dialog closes.

PHP, backend and database

Run a supported PHP versionCheck the PHP supported versions page on php.net; versions past end of life receive no security fixes.
Use prepared statements for every database queryPDO or MySQLi prepared statements with bound parameters prevent SQL injection.
Escape output with htmlspecialchars()Escape for the context you are writing into (HTML, attribute, URL or JavaScript).
Hash passwords with password_hash()Verify with password_verify(). Never store plain text or use MD5 or SHA-1 for passwords.
Keep credentials out of codeStore database passwords and API keys in environment variables or a config file outside the web root, and add it to .gitignore.
Turn off display_errors in productionLog errors to a file instead so visitors never see paths or queries.
Design tables with correct types, keys and indexesUse primary keys, foreign keys where relationships matter and utf8mb4 for full Unicode support in MySQL.
Give the application database user only the privileges it needsThe web app rarely needs DROP or GRANT; do not connect as root.

Security basics

Serve the whole site over HTTPSInstall a TLS certificate (for example from Let's Encrypt) and redirect all HTTP requests to HTTPS with a 301.
Add CSRF tokens to every state-changing formCheck the token on the server for each POST request.
Set secure session cookie flagsUse Secure, HttpOnly and SameSite=Lax (or Strict), and regenerate the session ID on login.
Add basic security headersContent-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy and Strict-Transport-Security once HTTPS is stable.
Restrict file uploadsCheck type and size on the server, rename files and store them where they cannot be executed.
Rate-limit login and contact formsLimit attempts and consider a CAPTCHA or honeypot field to cut spam and brute-force attacks.
Remove test files, phpinfo() pages and directory listingsAnything left on the server can be found and used by attackers.

Performance

Compress and resize images; use WebP or AVIF where supportedServe images no larger than they are displayed, with width and height set to prevent layout shift.
Lazy-load below-the-fold images with loading="lazy"Do not lazy-load the main hero image, which is often the Largest Contentful Paint element.
Enable compression and browser cachingTurn on Brotli or gzip and set cache headers for static files such as CSS, JS and fonts.
Minify CSS and JavaScriptUse a build step or your framework's asset pipeline.
Check Core Web VitalsAim for good LCP, INP and CLS. Test with PageSpeed Insights and Lighthouse on a mobile profile.
Limit web fontsLoad only the weights you use and set font-display: swap.

SEO basics

Write a unique title tag and meta description for every pageKeep titles descriptive and close to 60 characters so they are less likely to be cut short.
Use clean, readable URLsLowercase words separated by hyphens, for example /services/web-design/.
Add a canonical tag to each indexable pageIt tells search engines the preferred URL when duplicates exist.
Create robots.txt and an XML sitemapMake sure robots.txt does not block CSS, JS or pages you want indexed, and list the sitemap URL in it.
Remove noindex left over from stagingA forgotten noindex tag or blocking robots.txt is a classic launch mistake.
Add structured data where it fitsFor example Organization or LocalBusiness markup. Validate with Google's Rich Results Test.
Set up Google Search Console and submit the sitemapVerify the domain property and watch the indexing reports after launch.

Deployment and backups

Deploy from version control, not by editing live filesUse Git-based deployment or a repeatable SFTP process so you always know what is live.
Test every form, email and payment flow on the live siteSend real test submissions and confirm emails arrive and are not marked as spam.
Set up 301 redirects for any changed URLsMap old URLs to the closest new page to keep links and rankings.
Configure automatic backups of files and databaseKeep copies off the hosting server and test a restore before you rely on them.
Add uptime monitoringA free uptime monitor alerts you when the site goes down or the certificate is about to expire.
Set up analytics and respect consent requirementsInstall analytics and add a privacy policy that explains what you collect.
Hand over documentation and logins securelyShare credentials through a password manager, not email or chat.

Frequently asked questions

Which WCAG level should a normal business website meet?

WCAG 2.2 Level AA is the widely accepted target for public websites. It covers contrast, keyboard access, labels, focus visibility and more.

Do I need a framework to follow this checklist?

No. Every item applies to a hand-coded site, a PHP framework such as CodeIgniter or Laravel, or a CMS such as WordPress.

When should I use the checklist?

Use the planning section before you start, the build sections during development and the full list on staging before launch.

Is Lighthouse enough to test accessibility?

No. Automated tools catch only part of the problems. Always test with the keyboard and, if possible, a screen reader such as NVDA or VoiceOver.

Website Development Checklist

How to use this checklist

Planning

HTML, semantics and accessibility

CSS and responsive layout

JavaScript

PHP, backend and database

Security basics

Performance

SEO basics

Deployment and backups

Frequently asked questions

Which WCAG level should a normal business website meet?

Do I need a framework to follow this checklist?

When should I use the checklist?

Is Lighthouse enough to test accessibility?

Want to Learn This Properly?

How to use this checklist

Planning

HTML, semantics and accessibility

CSS and responsive layout

JavaScript

PHP, backend and database

Security basics

Performance

SEO basics

Deployment and backups

Frequently asked questions

Which WCAG level should a normal business website meet?

Do I need a framework to follow this checklist?

When should I use the checklist?

Is Lighthouse enough to test accessibility?

More free templates

Want to Learn This Properly?