An accessible preview link proves that a page exists. Using it to serve customers also requires reliable data handling and working services. A brochure website needs a different level of testing from a site with accounts, bookings, or payments. Start with these six checks and fix any problems before opening the site to the public.
1. Are the content and materials accurate?
Remove sample phone numbers, test addresses, invented reviews, and services you do not yet offer. Confirm publication rights for images, fonts, and project examples. In particular, do not place AI-generated office or team photos on an About page in a way that suggests they show your real business. Label conceptual imagery and provide the factual information customers need to decide.
2. Can customers complete the main task on a phone?
Open the production environment on your own phone and test menus, text, images, forms, and contact buttons. Narrowing a desktop browser is not a complete mobile check. Watch for the keyboard covering the submit button, unclear error messages, and slow images or video. Ask someone uninvolved in the project to try the journey and observe where they hesitate.
3. Does submitted information actually arrive?
Send a test inquiry and confirm the record, notification, and recipient. Test missing required fields, invalid formats, and repeated clicks so a success message never conceals missing data. For booking or payment features, also check failures, cancellations, and retries. Payment status should be confirmed through trusted payment-provider notifications, rather than a success message shown in the browser.
4. Are permissions and secrets protected?
Public pages must not expose passwords, database connection details, or private keys. Administrative functions and data operations need authorization; hiding an admin URL is insufficient. Ask a qualified technical owner to examine server-side validation, data access, and dependency updates. Accounts and transactions require particular care and real testing. Generated code does not establish that these protections work.
5. Are the production URL and search settings correct?
Check the production domain, HTTPS, page titles, descriptions, and internal links for preview-site references. Ask a technical specialist to check for accidental indexing restrictions and inspect important URLs in Search Console. A sitemap helps search engines discover pages but guarantees neither indexing nor rankings. Restrict access to test environments appropriately so they are not confused with the production site.
6. Who can restore the site if something breaks?
Document domain, hosting, code, and data administration, including renewal dates, backup locations, and support contacts. Confirm that backups can actually be restored. If nobody can resolve failures yet, reduce the initial public scope: launch service information and a tested contact method first, then add more complicated features when the team can support them.
Checks you can start with
- Remove sample data and unverified claims.
- Test mobile use and inquiry notifications on the production URL.
- Have a technical owner review permissions, secrets, and indexing settings.
- Document accounts, renewals, and recovery responsibilities.
A practical next step
To assess whether the current version is ready, collect the website link, essential features, and test results. Fix the issues that would disrupt operations before scheduling launch; visual completeness alone is not a reliable acceptance standard.
Explore our brand website and visual design services, or share your website and requirements through our contact page to discuss an appropriate scope.
Related reading
Building a website with AI? Five decisions people still need to make
References
References checked on November 2, 2026. Situations and figures are explanatory examples, not customer results, service quotations, or performance guarantees.