# Website launch checklist Morten A. Giraffe · Website launch field guide https://www.mortenagiraffe.com/journal/website-launch-checklist Write the URL, build, device and date at the top of your copy. Check a step after you run it. Record the outcome in the evidence sheet. ## 1. Trace one submission through the privacy policy A visitor should be able to tell who receives their details and how to ask about them. Watch for: The form asks for a project budget and sends email, but the policy discusses only cookies. - [ ] Pick one form. Follow each field from the browser through the server to the mailbox, database or delivery service that receives it. - [ ] Compare those recipients and purposes with the published policy. Ask the operator who handles requests and what retention practice they actually follow. Evidence to save: Save a field-to-recipient map and the owner’s answer about retention. An unknown retention period stays open for the owner. A technical walkthrough covers factual accuracy. Further reading: [FTC guide to handling personal information](https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business) ## 2. Measure the image that actually arrives A phone can spend seconds downloading pixels that never appear on screen. Watch for: A thumbnail looks small in the layout but fetches the same large file as a full-width hero. - [ ] Choose a representative image. At two viewport widths, record the displayed width, device pixel ratio and image URL selected by the browser. - [ ] With the browser cache disabled, record response format and transferred bytes. Inspect the result for blurry text, cropped faces or visible compression damage. Evidence to save: Keep a Network entry and screenshot for each size. A warm-cache response can show zero transferred bytes, so record the cache setting alongside the result. Further reading: [web.dev guide to responsive image selection](https://web.dev/learn/images/descriptive) · [Chrome DevTools Network reference](https://developer.chrome.com/docs/devtools/network/reference) ## 3. Make the terms fit the actual offer People need to understand what they receive and what they may do with it. Watch for: A free download carries subscription cancellation terms, or a portfolio suggests visitors may reuse client artwork. - [ ] List the things a visitor can do today, such as download a template, run a tool, request a quote or pay. Read the terms against each action. - [ ] Ask the owner to confirm who operates the site, which permissions they can grant, and where a separate project agreement begins. Evidence to save: Save the offer inventory and owner-confirmed permissions. Mark a licensing or jurisdiction question for qualified review if the owner cannot resolve it. Further reading: [Creative Commons guide to license choices](https://creativecommons.org/share-your-work/cclicenses/) ## 4. Separate a slow test from a slow audience A repeatable lab run can locate a bottleneck. Real-user data tells you whether visitors encounter it. Watch for: A high performance score is quoted even though the largest visible element appears late on a simulated mobile connection. - [ ] Choose a landing page and one task page. Save the build, device profile, throttling, cache state and largest contentful element with each lab result. - [ ] Check available field data for the same URL or origin, device and period. Record LCP, INP and CLS when available. Label the source and leave missing data unverified. Evidence to save: Keep the reports and identify the slowest request or render step before proposing a fix. A load test’s total blocking time cannot supply a missing field INP measurement. Further reading: [Google PageSpeed Insights methodology](https://developers.google.com/speed/docs/insights/v5/about) ## 5. Inspect what ships to the browser Anyone who can load a page can inspect its scripts, public files and network responses. Watch for: A client component imports a delivery helper, or a privileged integration key uses a public environment-variable prefix. - [ ] Trace the boundary around each service that can send email, write records or charge money. Check which modules the client imports. - [ ] Scan public assets and the production client bundle for known credential patterns. Record file names and counts only. Distinguish public measurement identifiers from credentials that grant access. Evidence to save: Record the build and scan scope, including skipped file types. A clean pattern scan leaves repository history, provider accounts and unrecognized formats outside its coverage. Further reading: [Next.js documentation on server and browser environment variables](https://nextjs.org/docs/app/guides/environment-variables) ## 6. Read the quietest text on its real background Dates, instructions and errors often carry the information someone needs most. Watch for: Body copy looks clear, but a small gray error or date disappears against a textured panel. - [ ] Inspect a label, error, link and focus state. For translucent text, use its color after blending with the background. - [ ] Compare normal text with the 4.5:1 WCAG AA threshold and large text with 3:1 where applicable. Check gradients, images and overlapping layers at their least legible point. Evidence to save: Save the text, its state, the foreground and background, and the unrounded result. Record items an automated tool could not evaluate for visual review. Further reading: [W3C explanation of minimum text contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) ## 7. Follow the request all the way to HTTPS An encrypted page still relies on the URLs of its images, scripts, styles and forms. Watch for: The address bar shows HTTPS, yet an old embed fails or a form points to an insecure destination. - [ ] Request the HTTP version of a public page and follow each redirect. Check the final HTTPS hostname and response status. - [ ] Inspect resource URLs in returned HTML and runtime network activity. Include script sources, CSS-loaded images and form destinations. Review the browser’s mixed-content messages. Evidence to save: Save the redirect chain and the resource or status for each failure. Record which templates ran in a browser because static HTML alone misses requests made later. Further reading: [W3C Mixed Content specification](https://www.w3.org/TR/mixed-content/) ## 8. Finish the task with less room Navigation, reading and recovery should remain usable on a narrow screen or with enlarged text. Watch for: The menu opens but keyboard focus stays behind it, or a sticky button covers the error message. - [ ] At a 320 CSS pixel viewport, follow a real task. Check horizontal scrolling, menus, form errors and fixed controls. Repeat with browser zoom or larger text where available. - [ ] Use the keyboard to open and close the menu, then check where focus lands. Look for cramped adjacent targets. Record any size or spacing exception you rely on. Evidence to save: Record viewport and input method with the result. Resizing a desktop window provides reflow evidence. Native device, browser zoom and assistive technology checks each require their own observation. Further reading: [W3C explanation of reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) · [W3C explanation of target size and exceptions](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) ## 9. Try every consent choice in a clean session A visitor’s choice should determine which optional services receive activity. Watch for: A banner says analytics is optional while a tracker or counting cookie already appears before a choice. - [ ] Write down the promised behavior for a fresh visit, decline, allow, withdrawal and reload. Separate the choice preference and any necessary request processing from optional measurement. - [ ] In an isolated test with provider traffic intercepted, inspect scripts, requests and cookies at each step. Wait for delayed batches after withdrawal and check a second tab. Evidence to save: Save a timed request and storage record for each state. Document advertising permissions separately from analytics and identify any transmission already in flight when consent changed. Further reading: [Google guidance on basic and advanced consent mode](https://developers.google.com/tag-platform/security/concepts/consent-mode) ## 10. Give a lost visitor a real way back Someone following a stale link needs a useful next step and an accurate response from the server. Watch for: A friendly missing-page message arrives with HTTP 200, or its only recovery link leads back to the missing address. - [ ] Request a made-up public path. Record the actual HTTP status and the page a person sees. - [ ] Follow one recovery link with a keyboard. For a genuinely moved page, separately verify that the redirect lands on its relevant replacement. Evidence to save: Keep the response status, recovery destination and resulting status. A screenshot alone cannot distinguish a real 404 from a success response that displays an error. Further reading: [Google guidance on HTTP errors and soft 404s](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) ## 11. Tell similar pages apart in a search result A useful title identifies the page. Its description gives a reader a reason to choose it. Watch for: Every service has the same title, or the description promises an offer that has disappeared from the page. - [ ] Read the returned title and description for a home, detail and collection page. Compare them side by side with the first heading and actual offer. - [ ] Check for repeated templates and cut filler. Keep any team character budget explicit. Google can generate different title links and snippets for a query or device. Evidence to save: Save the URL, rendered title, description and page intent. A later search-result observation establishes what Google showed for that query and date. Further reading: [Google Search Central on title links](https://developers.google.com/search/docs/appearance/title-link) · [Google Search Central on snippets](https://developers.google.com/search/docs/appearance/snippet) ## 12. Follow links to the promised destination A link can return a page and still leave the reader in the wrong place. Watch for: A “See pricing” link loads the top of a long page because its section ID changed. - [ ] Sample links from the header, footer, cards and article body. Record the source, link text, status of each hop and final destination. - [ ] For a fragment, check the target ID after the page loads and confirm the heading is visible beneath any sticky header. Separate an external refusal or timeout from a confirmed missing page. Evidence to save: Save the source-to-destination pair, status and visible result. State the number of links sampled and how many remained outside the sample. Further reading: [Google Search Central on crawlable, descriptive links](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) ## 13. Read the page as a link preview A shared link should identify the specific story, project or offer before someone opens it. Watch for: A project link expands into a generic homepage card, or the image works only when the owner is logged in. - [ ] Read the Open Graph title, type, URL and image from the public response. Confirm they describe the page being shared. - [ ] Fetch the absolute image URL without credentials. Check the response type, dimensions and a small crop where text or a face could be cut off. Evidence to save: Keep the tags and image response. To verify a particular platform’s crop or cached card, inspect that platform’s actual preview separately. Further reading: [Open Graph protocol and image properties](https://ogp.me/) ## 14. Make a failed form worth retrying A person who has written a thoughtful inquiry should be able to fix one field or retry a delivery failure. Watch for: “Please try again” appears, but the page has cleared the message or moved focus away from the problem. - [ ] In a local fixture, submit one invalid field. Check its label, error association, focus and entered values. Send a tampered request directly to the action to verify server validation. - [ ] Simulate the essential email send failing, then retry. Separately fail the confirmation after essential acceptance. Check the message and number of sends in both cases. Evidence to save: Save the visible states, retained fields and fixture send counts. Provider acceptance and confirmed inbox arrival require separate evidence when testing a real delivery. Further reading: [W3C tutorial on form validation](https://www.w3.org/WAI/tutorials/forms/validation/) · [W3C tutorial on form notifications](https://www.w3.org/WAI/tutorials/forms/notifications/) ## 15. Look at the icon at tab size A small, recognizable mark helps people find the site among open tabs and bookmarks. Watch for: The browser tab shows a framework icon, or the brand name becomes an unreadable row of pixels. - [ ] Read the published icon links and request their files. Compare declared dimensions and media types with the actual assets. - [ ] Open the smallest variant at its native size and compare it with the approved source. Check larger square assets separately for launchers or search. Evidence to save: Keep the icon URL, response, measured dimensions and a native-size visual check. Browser caching and a search engine’s choice of icon need separate observation. Further reading: [Google Search Central favicon guidelines](https://developers.google.com/search/docs/appearance/favicon-in-search) ## 16. Test abuse protection and a genuine retry A form should reject automated abuse while giving a real visitor a recoverable delivery path. Watch for: A fast double-click sends two messages, or an unavailable rate-limit service silently loses a legitimate inquiry. - [ ] Use a disposable local fixture. Exercise a honeypot, repeated request, configured rate limit and unavailable storage. Count actual attempted deliveries. - [ ] Fail the essential send, then repeat the same request. A duplicate marker written before delivery can mistakenly suppress that retry. Evidence to save: Write down which failure policy the owner chose, what happens during the outage and whether duplicate protection resumes. Leave live abuse testing to a separately authorized exercise. Further reading: [OWASP guidance on automated abuse and layered defenses](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) ## 17. List the pages you actually want discovered A sitemap supplies preferred URLs. Crawling and indexing depend on additional signals. Watch for: The sitemap lists redirected or excluded pages, or someone relies on robots.txt to hide confidential material. - [ ] Compare sitemap URLs with the intended public route list. Sample status, canonical URL and indexing directives across route types. - [ ] Read robots.txt as a crawler would for the relevant user agent. Protect private content through access controls. Check Search Console separately for actual indexing observations. Evidence to save: Save sitemap and robots responses plus representative URL checks. A sitemap entry, successful fetch or indexing request alone cannot establish index inclusion. Further reading: [Google guidance on building a sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) · [Google introduction to robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro) ## 18. Count the outcome the report claims A business decision depends on knowing what had to happen for an event to count. Watch for: The dashboard counts every submit click as a lead, including invalid forms and duplicate retries. - [ ] Define one event in plain language. Trace its trigger through acceptance, duplicates, consent and SDK readiness. Inspect the actual destination and payload with a local collector. - [ ] Test a single-page navigation and one accepted synthetic inquiry alongside failures and retries. Check that page views have one owner and that form fields, raw queries and receipt IDs never enter the payload. Evidence to save: Record application triggers, intercepted sends and payload fields separately. A live provider receipt requires its own approved test. Keep QA events distinguishable in business reporting. Further reading: [Google Analytics recommended events](https://developers.google.com/analytics/devguides/collection/ga4/reference/events#generate_lead) · [Google Analytics guidance on avoiding personal information](https://support.google.com/analytics/answer/6366371) ## 19. Describe what the image contributes here A reader who cannot see an image should still get the information or action it provides. Watch for: A case-study screenshot is announced as “image123.png,” while a decorative flourish interrupts the headline. - [ ] Read the paragraph and link around the image. Decide whether the image informs, decorates, or is the only content naming an action. - [ ] For an informative image, write the useful detail. Give decorative images an empty alt attribute. If an image is the only label in a link, ensure the link has an accessible name that describes its destination. Evidence to save: Review representative images in context and read the page with images unavailable. A scan for missing attributes can find omissions but cannot judge whether the descriptions convey the right meaning. Further reading: [W3C decision tree for image alternatives](https://www.w3.org/WAI/tutorials/images/decision-tree/) ## 20. Make the next action predictable A visitor should know what will happen before choosing the primary action. Watch for: Three equally prominent buttons all say “Get started,” and each leads to a different commitment. - [ ] Name the page’s main job and the visitor’s likely next step. Read the primary action aloud with the heading. Check whether its label predicts the destination or result. - [ ] Reach the action by keyboard and on a narrow screen. Follow the link, or exercise an action in a fixture, and compare the destination’s heading with the promise. Evidence to save: Keep the starting page, label and resulting screen together with the keyboard-focus observation. Whether a different label improves conversions needs a separate measurement. Further reading: [GOV.UK Design System guidance on button wording and use](https://design-system.service.gov.uk/components/button/)