← JournalField guide / 09
Release inspection manual
Before You Call It Done
20 website launch checks
Your contact form says “sent.” Did anything arrive? Pick one promise your site makes, try it as a visitor and keep the evidence.
Contents / 01–20
Find your check.
The numbers follow the original checklist. Use the map above for a team review, or jump to the check that needs an answer today.
- 01Trace one submission through the privacy policy
- 02Measure the image that actually arrives
- 03Make the terms fit the actual offer
- 04Separate a slow test from a slow audience
- 05Inspect what ships to the browser
- 06Read the quietest text on its real background
- 07Follow the request all the way to HTTPS
- 08Finish the task with less room
- 09Try every consent choice in a clean session
- 10Give a lost visitor a real way back
- 11Tell similar pages apart in a search result
- 12Follow links to the promised destination
- 13Read the page as a link preview
- 14Make a failed form worth retrying
- 15Look at the icon at tab size
- 16Test abuse protection and a genuine retry
- 17List the pages you actually want discovered
- 18Count the outcome the report claims
- 19Describe what the image contributes here
- 20Make the next action predictable
Fig. 02Two paths through a consent choice
Essential
Serve the page and process a requested action.
Optional
- No choiceHold measurement.
- AllowMeasure within the stated choice.
- WithdrawBlock future measurement requests.
Trace one submission through the privacy policy
A visitor should be able to tell who receives their details and how to ask about them.
- Warning sign
- The form asks for a project budget and sends email, but the policy discusses only cookies.
- Proof 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.
Run check 01 · Steps, example and prompt
What to inspect
- 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.
Worked example
An abuse counter may expire after an hour while the inquiry stays in a mailbox. Give each its own explanation. Describe a configurable onward integration conditionally until its use is confirmed.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Trace one synthetic form’s fields through the code without sending it. Compare the recipients, purpose, retention and contact details with the policy. List any fact only the operator can confirm.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Make the terms fit the actual offer
People need to understand what they receive and what they may do with it.
- Warning sign
- A free download carries subscription cancellation terms, or a portfolio suggests visitors may reuse client artwork.
- Proof 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.
Run check 03 · Steps, example and prompt
What to inspect
- 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.
Worked example
A free worksheet can help a reader review their own site. Downloading it does not commission a professional review or grant permission to republish someone else’s logo.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Compare the actual forms, tools, downloads and payment paths with the terms. Flag unsupported promises or missing usage boundaries. Identify which decisions require the owner or legal advice.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Try every consent choice in a clean session
A visitor’s choice should determine which optional services receive activity.
- Warning sign
- A banner says analytics is optional while a tracker or counting cookie already appears before a choice.
- Proof 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.
Run check 09 · Steps, example and prompt
What to inspect
- 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.
Worked example
A site can remember a decline and increment a daily total for that choice. If a person later allows and withdraws, those are distinct actions. The totals cannot tell you how many unique people visited.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Compare consent copy with local intercepted traffic and storage before a choice, after decline, after allow and after withdrawal. Check delayed sends and cross-tab behavior. Identify exactly what a choice counter represents.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.B Delivery
Follow the request all the way through.
What happens after someone clicks?
Back to contents ↑Fig. 03Where did the form submission stop?
- 01 · ValidateMissing or malformed fieldReturn a field error
- 02 · ScreenSpam signal or repeated attemptSuppress or limit the send
- 03 · DeliverProvider accepts or rejectsRecord the actual outcome
- 04 · ConfirmDelivery accepted, confirmation failsExplain the partial result
Inspect what ships to the browser
Anyone who can load a page can inspect its scripts, public files and network responses.
- Warning sign
- A client component imports a delivery helper, or a privileged integration key uses a public environment-variable prefix.
- Proof 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.
Run check 05 · Steps, example and prompt
What to inspect
- 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.
Worked example
A public analytics measurement ID identifies a destination. A mail-service API key can authorize sends and belongs on the server.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Trace one privileged integration from its form to its server entry point. Inspect environment variable names and scan the built client files with values redacted. If a candidate appears, report its location without printing or testing it.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Follow the request all the way to HTTPS
An encrypted page still relies on the URLs of its images, scripts, styles and forms.
- Warning sign
- The address bar shows HTTPS, yet an old embed fails or a form points to an insecure destination.
- Proof 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.
Run check 07 · Steps, example and prompt
What to inspect
- 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.
Worked example
A hard-coded HTTP script in a shared footer can break a feature on every HTTPS page even when the homepage redirects correctly.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Trace the HTTP-to-HTTPS redirect for one approved public URL. Inspect static and runtime resource schemes on a representative template, including the form action without submitting it. Report the originating file for any insecure request.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.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.
- Warning sign
- “Please try again” appears, but the page has cleared the message or moved focus away from the problem.
- Proof 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.
Run check 14 · Steps, example and prompt
What to inspect
- 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.
Worked example
For an emailed checklist the visitor’s resource is the essential send. For a project inquiry the owner’s notification may be essential. Choose the success message according to the actual promise.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Identify the essential delivery for one form. With fixture recipients, inspect client-invalid, server-invalid, delivery-failure, partial-success and retry paths. Verify focus, retained values and send counts.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Test abuse protection and a genuine retry
A form should reject automated abuse while giving a real visitor a recoverable delivery path.
- Warning sign
- A fast double-click sends two messages, or an unavailable rate-limit service silently loses a legitimate inquiry.
- Proof 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.
Run check 16 · Steps, example and prompt
What to inspect
- 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.
Worked example
A team may keep email available during a limiter outage and accept the extra abuse risk. A server-side scanning tool may instead stop accepting work while its quota store is unavailable.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Map the form’s rate limit, duplicate marker and outage behavior. Use local stubs for timing, repeated requests and delivery failures. Report whether a legitimate retry reaches the essential send.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Fig. 04One illustration, two byte counts
- Original guide artwork PNG
- 1,973,426 B
- Browser-selected variant 640 px · AVIF
- 13,836 B
Measure the image that actually arrives
A phone can spend seconds downloading pixels that never appear on screen.
- Warning sign
- A thumbnail looks small in the layout but fetches the same large file as a full-width hero.
- Proof 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.
Run check 02 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, a Morten guide illustration had a 1,973,426-byte PNG master. At the sampled 640px width, the browser received a 13,836-byte AVIF. Editing the master would have addressed a different file.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Compare one hero and one thumbnail at two widths. Trace currentSrc, rendered size, device pixel ratio, format and cold-cache transfer bytes. Suggest a change only where delivery or visible quality warrants it.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.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.
- Warning sign
- A high performance score is quoted even though the largest visible element appears late on a simulated mobile connection.
- Proof 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.
Run check 04 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, Morten’s three mobile lab runs scored 90–91 while LCP ranged from 3.39 to 3.60 seconds. Search Console had insufficient usage data for both device groups.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Read existing lab and field reports. For the slowest page, name the LCP element and its critical requests. Separate field data from lab metrics and propose one reproducible comparison.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Read the quietest text on its real background
Dates, instructions and errors often carry the information someone needs most.
- Warning sign
- Body copy looks clear, but a small gray error or date disappears against a textured panel.
- Proof 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.
Run check 06 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, a Morten policy timestamp measured 4.47:1. Raising the text opacity brought the sampled ratio to 6.09:1. Rounding the first result to one decimal would have hidden the failure.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Inspect the least prominent text on the approved pages. Capture its actual foreground and background, size, state and unrounded contrast ratio. Identify an existing color treatment that would correct any measured failure.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Finish the task with less room
Navigation, reading and recovery should remain usable on a narrow screen or with enlarged text.
- Warning sign
- The menu opens but keyboard focus stays behind it, or a sticky button covers the error message.
- Proof 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.
Run check 08 · Steps, example and prompt
What to inspect
- 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.
Worked example
A team can choose 44px touch controls as its design target. WCAG 2.2 AA’s target-size criterion uses 24×24 CSS pixels with specified exceptions, including spacing.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Walk the primary task at a narrow viewport with a keyboard. Inspect overflow, touch target spacing, error visibility, menu focus and Escape return. Record which native-device or zoom checks remain open.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.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.
- Warning sign
- A friendly missing-page message arrives with HTTP 200, or its only recovery link leads back to the missing address.
- Proof 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.
Run check 10 · Steps, example and prompt
What to inspect
- 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.
Worked example
A missing case study can offer a “Browse the work” link and return 404. A renamed case study with a known successor can redirect directly to that project.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Check one nonexistent path and one known moved path. Record each HTTP chain, visible recovery option and destination. Distinguish an intentional 404 from an incorrect success response.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Describe what the image contributes here
A reader who cannot see an image should still get the information or action it provides.
- Warning sign
- A case-study screenshot is announced as “image123.png,” while a decorative flourish interrupts the headline.
- Proof 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.
Run check 19 · Steps, example and prompt
What to inspect
- 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.
Worked example
Beside a case-study explanation, “Repair and installation appear as separate choices” may communicate the design decision. A decorative stroke under the heading can use alt="".
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Classify a representative content image, decorative image and linked image. Compare each image with its surrounding text and accessible name. Propose only the descriptions or empty alternatives that improve meaning.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Make the next action predictable
A visitor should know what will happen before choosing the primary action.
- Warning sign
- Three equally prominent buttons all say “Get started,” and each leads to a different commitment.
- Proof 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.
Run check 20 · Steps, example and prompt
What to inspect
- 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.
Worked example
“Start a project” can open an inquiry form. “Browse the work” offers supporting evidence for visitors who want it first. Both labels describe the next step.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Follow the primary task on one landing page at desktop and mobile widths. Compare the action label with the destination and test keyboard reachability. Suggest a clearer verb only if the present promise is ambiguous.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Fig. 05Read a page preview from the outside in
- Icon
- A recognizable mark at tab size.
- Title and description
- The page topic and what a reader will find.
- Canonical
- The preferred URL, for example
/guides/tap-repairon the intended HTTPS origin. - Social image
- An accessible, absolute image URL with artwork that survives a crop.
Tell similar pages apart in a search result
A useful title identifies the page. Its description gives a reader a reason to choose it.
- Warning sign
- Every service has the same title, or the description promises an offer that has disappeared from the page.
- Proof 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.
Run check 11 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, Morten’s Journal description went from 178 to 137 characters to meet the project’s under-155 editorial target. That change makes no prediction about rankings.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Compare the title, description and heading across three page types. Flag duplication or misleading copy and propose a distinct description that fits the page and the team’s stated budget.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Follow links to the promised destination
A link can return a page and still leave the reader in the wrong place.
- Warning sign
- A “See pricing” link loads the top of a long page because its section ID changed.
- Proof 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.
Run check 12 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, one Morten prompt fragment appeared missing in server HTML. Opening the link in a browser showed that its target appeared after the page became interactive.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Follow a bounded sample of internal links and fragments. Verify the final page and visible target, including after client rendering where needed. Separate confirmed broken links, redirects and unavailable external checks.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Read the page as a link preview
A shared link should identify the specific story, project or offer before someone opens it.
- Warning sign
- A project link expands into a generic homepage card, or the image works only when the owner is logged in.
- Proof 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.
Run check 13 · Steps, example and prompt
What to inspect
- 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.
Worked example
A portfolio case study can use its own project title and a recognizable project image. A protected preview image would leave a public sharing service unable to fetch that artwork.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Inspect one shareable page’s returned Open Graph metadata and image response. Compare the artwork at card size with the visible page. State which platform-specific previews were actually checked.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Look at the icon at tab size
A small, recognizable mark helps people find the site among open tabs and bookmarks.
- Warning sign
- The browser tab shows a framework icon, or the brand name becomes an unreadable row of pixels.
- Proof 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.
Run check 15 · Steps, example and prompt
What to inspect
- 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.
Worked example
On October 30, 2026, Morten’s site added a 16×16 PNG generated from its existing portrait while preserving the larger icon family.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Trace the declared favicon family to the actual files. Check the smallest icon and a larger square at native size. If a size is missing, identify the approved source and existing generation path.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.List the pages you actually want discovered
A sitemap supplies preferred URLs. Crawling and indexing depend on additional signals.
- Warning sign
- The sitemap lists redirected or excluded pages, or someone relies on robots.txt to hide confidential material.
- Proof to save
- Save sitemap and robots responses plus representative URL checks. A sitemap entry, successful fetch or indexing request alone cannot establish index inclusion.
Run check 17 · Steps, example and prompt
What to inspect
- 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.
Worked example
A public article can belong in the sitemap while a duplicate prompt-detail route is intentionally excluded. Document both decisions so the next audit can distinguish intent from a missing entry.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Compare intended public routes with the sitemap, robots rules, canonical tags and index directives. Inspect a small representative sample. Explain each intentional omission and keep actual indexing observations separate.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Count the outcome the report claims
A business decision depends on knowing what had to happen for an event to count.
- Warning sign
- The dashboard counts every submit click as a lead, including invalid forms and duplicate retries.
- Proof 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.
Run check 18 · Steps, example and prompt
What to inspect
- 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.
Worked example
An accepted inquiry can emit one generate_lead event. The owner still needs a separate process to decide whether the inquiry qualifies or becomes a sale.
Primary reading
Prompt for this check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Trace one page view and one lead from the UI to an intercepted collector. Check duplicate navigation, invalid input, accepted requests, retries and consent changes. Report event counts and safe property names without personal values.
Return a read-only finding with the page or file, what you observed, what remains unknown and the smallest justified change.Release record
Give each result a scope.
In the October 30, 2026 review of this site, twelve checks had enough evidence for the tested scope. Eight stayed partial. For those eight, the next step mattered more than a score.
Fig. 06A release evidence sheet
Verified
The missing page returned 404 and its Home link worked.
Save the response and the recovery screenshot.
Partial
The form accepted the test request. Mailbox delivery is still unconfirmed.
Ask the recipient to check delivery.
Unverified
The site has too little usage data to report field INP.
Record the reporting window and revisit.
Not applicable
This brochure site has no customer accounts.
Record who checked that scope and when.
Working with an assistant
Choose a prompt for the job.
Copy a prompt and replace the bracketed scope with the routes, files and actions you can authorize. The Context Engine guide explains how to keep those instructions with your project.
Investigate a launch check
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Investigate check [number] on [representative route]. Name the visitor’s task and the expected behavior. Trace the actual implementation and reproduce the suspected failure locally. Use existing evidence when it covers the same build and behavior.
Return the observed symptom, reproduction steps, relevant file or URL, and the limits of the test. Mark the check verified, partial, unverified or not applicable and explain why.Repair a confirmed issue
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Use the confirmed finding for check [number] and its reproduction [evidence]. Make the smallest local fix in [approved files]. Follow the existing design and validation patterns. Preserve consent, form data, error recovery and working navigation.
Repeat the original reproduction and one nearby success or failure case. Report changed files, commands, results and a specific rollback step. Identify any release or operator decision still needed.Verify the release evidence
Work in [site or repository] using [stack], limited to [approved pages or features]. Read the project instructions first. Use synthetic inputs and redact personal data and credentials. Ask before any live submission, provider change, push or deployment.
Review [candidate build or commit] against the approved launch checks. Identify the environment and sample for each claim. Compare the built page with the expected behavior using authorized read-only requests or local fixtures. Record a fresh result when the change invalidates old evidence.
Return a table with check number, status, actual result, evidence, known limit and next owner. Distinguish local results, preview behavior, deployment state and observed production behavior. Leave any unapproved live verification open.Take it with you
Three working files.
Open the Markdown files in a text editor. Keep the checklist in your project, add evidence as you go and hand the next person a dated record.