A contact form may work on staging but fail after launch because the live site sends messages from a different domain. For an architecture practice or property team, that can mean lost project enquiries even though the pages look fine. Before announcing the site, submit a form on the public address, confirm the message arrives, and check who will reply.
Treat this checklist as a release gate, not a backlog. Give each item an owner and mark it pass, fail, or accepted exception. A small brochure site may take one short test session; property availability, appointment booking, downloads, or multiple languages call for more time and realistic test cases.
1. Define what is actually being launched
Agree on the scope before the final review. List the public pages, forms, downloads, languages, integrations, and content that will remain unpublished. Identify both the staging address and production domain so reviewers know which version they are approving. If the site replaces an older one, export its page inventory and flag addresses that must continue to work.
- Decision owner: Name the person authorized to approve launch or accept a documented exception.
- Technical owner: Record who controls the domain, hosting, backups, deployment, and emergency rollback.
- Content owners: Assign someone to check each service, project, building, and contact detail.
- Release window: Pick a time when the team can test the live site and respond to faults, not merely press publish.
Keep a brief issue log with the affected URL, steps to reproduce, severity, owner, and retest result. Distinguish launch blockers, such as a broken enquiry route or exposed confidential plans, from minor polish that can wait.
2. Check facts, permissions, and claims
A project page is not ready just because its photographs and text look finished. Verify the name, location, building type, scope of work, completion status, and the practice’s role. Make it clear whether an image shows a completed building, a proposal, or a visualization. Check any published area, budget, energy target, certification, or accessibility feature against an approved record, and name the measure precisely: gross floor area, net usable area, and site area mean different things.
Check ownership and publication permission for photographs, plans, renders, quotations, testimonials, logos, and images of identifiable people. Review client agreements for restrictions on security-sensitive layouts, costs, or unbuilt proposals. For public buildings, schools, and medical facilities, inspect downloadable drawings as well as the visible page for details not approved for release. Remove confidential filenames and document metadata where appropriate.
Open every download. Its filename should be descriptive, its contents should match the page, and its revision should be current. Provide a readable alternative if an essential document cannot be used by everyone. Ask the relevant owners to sign off on live staff biographies, addresses, opening hours, service areas, and property availability rather than relying on an old draft.
3. Walk the main visitor routes
Use the site as a prospective client, tenant, investor, or procurement officer would. Starting at the homepage, try to find the relevant service or property, evidence of suitable experience, practical constraints, and a way to make contact. Repeat the exercise from a project page or search result; many visitors will not start at the homepage.
Test navigation with a mouse, keyboard, and touch. Titles and headings should make each page identifiable, and contact details should be easy to find. For a building open to visitors, compare directions, access information, and opening times with current operations. If a page invites enquiries about a specific project, state clearly whether it is complete, under construction, or available for discussion.
Test forms as transactions, not decorations
- Send a valid test enquiry from a desktop browser and a phone.
- Enter incomplete or incorrectly formatted data; errors should be explained beside the relevant fields.
- Check that the success message says what happened without promising a response time the team cannot meet.
- Confirm delivery to the right mailbox or system, including spam filtering and internal notifications.
- Make sure the record contains what staff need to reply but does not request unnecessary personal data.
Test telephone and email links on a device that can use them. Where forms route enquiries by service, location, or property, test every route. Do not use a real client’s private information in a test record.
4. Check mobile use and accessibility
Desktop approval is not enough. Test the production site at several screen widths and orientations, including on a slower mobile connection. Watch for clipped navigation, overlapping text, unreadable plan captions, buttons obscured by consent banners, and tables that push the whole page sideways. Zoom in and increase the text size; important content and controls should still work.
Run an automated accessibility check, then test manually. Use only a keyboard to move through the site: focus should be visible, menus should open and close, and focus should not become trapped. Review heading order, link names, form labels, error messages, contrast, and alternative text for meaningful images. A photograph may need a short description; a complex site diagram or floor plan may also need nearby text explaining its purpose.
An automated pass is not proof of accessibility. A scanner may miss a project filter that changes results without announcing the change, or a PDF whose text is one large image. If a particular accessibility standard or procurement requirement applies, test against that standard and document unresolved exceptions.
5. Verify security, privacy, and site control
Check that every live page uses HTTPS and that visitors are redirected to the intended canonical address. Look for mixed-content warnings from files still loading over an insecure connection. Remove default accounts, unused plugins, sample pages, and public staging copies. Give editors only the access they need, and enable multifactor authentication where supported.
Compare the privacy notice with what the site actually collects through enquiry forms, analytics, embedded media, maps, mailing-list sign-ups, and scheduling services. Consent settings must follow the applicable rules in the site’s jurisdiction. A banner may look compliant while optional trackers load before visitors choose. Confirm that personal information goes only to intended recipients and is retained under the organization’s policy. Legal requirements vary by location; seek appropriate review for regulated or cross-border operations.
Back up the site before release and establish how to restore it. Record where the backup is, what it contains, and whether recovery has been tested. Also record who holds domain and hosting access, when certificates or subscriptions renew, and how another staff member can regain control if the usual administrator is unavailable.
6. Prepare search visibility without exposing staging
Staging should not appear as the public site. Once the production site is live, check representative pages for leftover noindex settings or robots rules that block indexing; do not assume one sitewide setting covers everything. Allowing indexing does not guarantee that every page will appear in search results, and visibility may take time.
Give important pages accurate titles and descriptive main headings. Check snippets for temporary wording such as “new project” or “coming soon.” If the site replaces an older one, map old URLs to the closest relevant new pages and set up permanent redirects. Sending every former project page to the homepage is less helpful than preserving its destination or pointing to a genuinely comparable page.
Generate a sitemap if the platform supports one, excluding staging, draft, and private URLs. On the live domain, check canonical addresses, navigation, image paths, and download links. For multilingual pages, make sure language switching leads to the corresponding page rather than an unrelated homepage.
7. Test speed and resilience on the live build
Large architectural photographs, background video, interactive maps, and document viewers can hold up useful content. Test representative pages on mobile and desktop, including a media-heavy project page and a form. Note the measured loading behavior, but also try using the page: can you read the project description while images load, and submit the form without waiting for an animation?
Size and compress images for their display context, choose suitable file formats, and do not load full-resolution drawings as thumbnails. Reserve image space so the page does not shift as files appear. Check that essential content remains available if a nonessential map, video, or third-party widget is slow or unavailable. Do not remove necessary information just to improve a performance score; address the delay without undermining the page’s purpose.
8. Release, verify, and monitor
Freeze major content changes for the final test window, then deploy the approved version. Clear caches where needed and inspect the public site in a private browser session so a locally cached page is not mistaken for the release. Test the domain with and without the common www prefix, confirm the intended redirect, and revisit a sample of pages changed during deployment.
Run a post-launch smoke test covering the homepage, key service pages, two or three project pages, navigation, search if present, downloads, a complete form submission for each routing path, and the 404 page for a nonexistent address. Review server or platform error reports. If analytics are in use, confirm they record test visits without collecting sensitive form fields. Label test submissions clearly so staff do not mistake them for real enquiries.
For the first few days, assign someone to check errors and incoming messages daily. Compare the live site with the approved scope, fix broken redirects, and log defects reported by staff or visitors. Retest changes to shared templates on a phone as well as a desktop. Before closing the issue log, send one final enquiry from an address outside the organization’s email system and confirm it reaches the assigned recipient with the correct project page identified.