SAYLOR Catch broken configuration, missing metadata, inaccessible controls, security-header gaps, dead links, form failures, and mobile problems before publication.
The result you're building
A launch candidate that passes functional, mobile, accessibility, metadata, security-header, form, analytics, performance, and recovery checks on the actual production hostname before traffic is sent to it.
Use this guide when
- Before publishing a new site or major release.
- Before changing DNS from an old production site to a new host.
Do not use it as a substitute for
- Do not treat a home-page screenshot or successful build as launch acceptance.
- Do not test forms/payments using real customer data unless the environment and cleanup are explicit.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Production hostname, release ID, sitemap/route inventory, and target devices/browsers.
- Business-critical journeys, forms, destinations, and legal/privacy copy.
- DNS/TLS/redirect/cache/security configuration.
- Backup, rollback deployment, owners, and launch window.
Understand the system before fixing it
A launch is a collection of journeys
Test what a visitor must accomplish, not only whether pages render.
Production hostname changes behavior
Cookies, CORS, redirects, canonical URLs, OAuth callbacks, CSP, and caches can differ from preview URLs.
Automated scans need manual checks
Keyboard focus, copy accuracy, mobile interaction, real email delivery, and business logic need human verification.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Page blank/console error | Frontend build/runtime | Network/console and asset paths | Wrong base URL, missing env, CSP, or bundle error. |
| Form says sent; nothing arrives | Backend/delivery | Submission ID, server log, provider event | UI success is not delivery proof. |
| Wrong canonical/indexing | SEO config | HTML, robots, sitemap, redirects | Preview/noindex or duplicate host leaked. |
| Works desktop, fails phone | Responsive/input | Real viewport/touch/keyboard tests | Overflow, fixed overlays, input zoom, or target sizing. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Freeze release and route inventory
Why: Changing code during testing invalidates results.
Do: Record deployment ID/commit, production config names, routes, status expectations, owners, and critical journeys.
Read the result: Every public route has an intended status/canonical/index rule.
Next: Test this immutable candidate.
Step 02 — Test domain, TLS, redirects, and headers
Why: A preview URL cannot prove production behavior.
Do: Verify DNS/TLS, apex/www/http redirects, canonical host, compression/cache, CSP/HSTS/referrer/content-type/frame policies appropriate to site.
Read the result: Redirects terminate once and headers do not block required assets.
Next: Keep origin/admin endpoints unexposed.
Step 03 — Exercise critical journeys
Why: Page load is not business completion.
Do: Run navigation, search, contact/lead, account, download, checkout/payment in safe test mode, error/empty states, and back/refresh behavior; trace each server-side outcome.
Read the result: UI result, backend record, notification/delivery, and analytics event agree.
Next: Delete/label test data.
Step 04 — Check mobile and accessibility
Why: Many visitors cannot use mouse/desktop assumptions.
Do: Use keyboard-only, visible focus, headings/labels/errors, zoom, contrast, motion preference, screen-reader smoke, real phone widths/touch targets.
Read the result: No trap, hidden focus, overlap, or unlabeled control blocks the journey.
Next: Record WCAG issues separately from legal claims.
Step 05 — Validate discovery and metadata
Why: Search/social previews depend on machine-readable details.
Do: Check unique title/description/canonical, robots, sitemap, Open Graph, favicon, structured data truthful to visible content, status codes, and dead links.
Read the result: Production pages are indexable only where intended; no preview hostname/copy remains.
Next: Submit only after launch.
Step 06 — Run rollback drill and observe launch
Why: Fast recovery needs more than a remembered button.
Do: Revert to prior deployment in a test/checkpoint, confirm DNS need not change, preserve database compatibility, set health/error/form alerts, and define stop thresholds.
Read the result: Rollback fits time objective and does not lose new submissions.
Next: Launch, smoke production, and monitor.
Worked example
Evidence collected
- Frontend displays success after any 200 response.
- Server accepts request but email provider rejects unverified sender domain.
- No delivery event or alert is checked.
- Test used preview hostname/config.
Decision: The critical journey fails after UI acceptance at the delivery provider boundary.
Actions taken
- Verified sender/domain and production environment.
- Stored submission before email, surfaced reference ID, monitored delivery failure.
- Tested real production hostname end-to-end.
Why this example matters: A website is not launched when its main business outcome silently fails.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Production hostname/TLS/redirect/canonical behavior is correct.
- Every critical journey passes end-to-end with backend evidence.
- Mobile/keyboard/accessibility blockers are resolved.
- Metadata/robots/sitemap/structured data match visible production content.
- Security/cache headers work without blocking the app.
- Rollback and monitoring thresholds are tested.
Rollback or safe recovery
- Promote/repoint to the prior immutable deployment.
- Disable failing form/payment feature while preserving submissions.
- Revert headers/config individually if they block assets or auth.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Only production login fails | Cookie/callback/origin environment differs. | Compare hostname, secure/samesite cookie, OAuth redirect, CORS. |
| Old content persists | CDN/browser/service-worker cache. | Identify cache layer and version/purge narrow assets. |
| Analytics missing | Consent/CSP/adblock/config or wrong property. | Verify network/event debug without blocking launch-critical function. |
| Rollback breaks database | Migration not backward compatible. | Use expand/contract or restore tested compatible release/data plan. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Release/route/journey inventory.
- DNS/TLS/redirect/header evidence.
- End-to-end functional and delivery records.
- Mobile/accessibility/SEO/dead-link report.
- Rollback drill, alerts, stop thresholds, and owners.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points