A business website staging environment should have its own application deployment, database, file storage and notification settings, with access limited to the acceptance team. Production uses the live domain, business records and approved recipients. Release an agreed list of changes, then repeat enquiry and SEO checks on the live URLs. Record the responsibilities and outcomes for previewing pages, testing business actions and serving customers.
This checklist covers connecting AI-generated pages to a CMS, upgrading a theme, redesigning a website and rehearsing backup restoration. Technical staff configure the environments; marketing or business staff verify content and enquiries. For initial deployment, use the self-hosted website checklist. For theme work, see the AI website and theme delivery guide.
1. Record what each environment connects to
Ask the actual maintainer to complete an environment register with resource identities, owners and verification dates. A staging domain identifies an entry point. Isolation also requires checking the application, data and external connections. Two environments can share a server when process permissions, directories, database accounts and network access are configured and tested. Projects requiring stronger isolation can use separate hosts or containers with corresponding resource permissions.
| Item | Staging and production requirements |
|---|---|
| Application and domain | Separate application directories and environment configuration; record domains, HTTPS, versions and deployment targets |
| Database | Separate databases and accounts with environment-specific permissions; verify the target before restoration |
| Images and attachments | Separate directories or storage spaces and credentials; check the destinations of public links |
| Email and external services | Test inboxes or capture tools and test credentials; list every actual CRM, SMS or other connection |
| Cache, sessions and jobs | Separate directories, connections or namespaces; start workers and scheduled tasks for the intended environment |
| Analytics and access | Identify or separate test analytics; name preview users and the production business owner |
Record configuration locations and resource identities in the register. Keep secrets in an authorized secure channel. Add a separate row for each payment, order, subscription, community or other project extension, and confirm its test mode, real-world effects and implementation owner.
2. Verify preview access and search indexing separately
For internal previews, prioritize authentication, a VPN or an IP allowlist at the gateway or server, covering pages, images, attachments and endpoints. An authorized person checks access; technical staff also test an unauthenticated session and a network outside the allowlist. Huawei Cloud's test-domain instructions in Chinese describe preview access and binding a customer-facing domain as separate operating scenarios.
For a temporarily public test page, technical staff can configure staging-specific noindex and inspect the HTML robots tag or X-Robots-Tag response header. Google needs crawler access to read the instruction; a robots.txt crawl block can prevent this. See Google's noindex documentation. Check each search platform's rules separately.
Use access controls for confidential previews and inspect indexing instructions independently for public pages. See Google's content visibility guidance. If staging results already appear in search, the site owner should follow the platform's removal process and track both the protection measures and subsequent results.
3. Isolate write targets before copying data or restoring backups
Before restoration, prepare a separate database, upload location and test notification destination. Then import approved samples or a suitably processed backup. Prefer fictional contacts and sample products. When real materials are required, establish access authorization, handling procedures and retention first. After import, recheck the database connection, form recipients, attachment links and external service settings before opening the environment to reviewers.
- Edit a product clearly identified as a sample in staging. Record its original and new values; verify that the corresponding production record retains its original value.
- Upload a file clearly labelled for testing. Confirm its storage location and public URL belong to staging.
- Check where staging cache, sessions and jobs operate, including which test workers process the jobs.
- Record the backup timestamp, application and theme versions, operator and exceptions for the next restoration exercise.
Release code, theme and content changes from an approved list. A full database replacement requires a separately reviewed data migration plan. Include production product edits, accounts and enquiries created during testing in the preservation and reconciliation scope. The rollback plan should also preserve records added after the backup. Use the deployment and maintenance guide for the broader restoration procedure.
4. Give every test enquiry a traceable destination
Staging can use log mail or a capture tool to inspect message content. To test actual delivery, use a dedicated test inbox and controlled notification settings. Check the application's default mail transport, every form's recipient addresses and any forwarding, CRM or webhook integration implemented for the project. Confirm all recipients before submitting a request labelled as a test. Where a mail service is used, verify outbound restrictions or a test-recipient allowlist as well.
The current CatchCMS form flow saves the submission first, then sends mail synchronously and records the notification state. Verify the mail transport and form recipients directly. A saved record, the sending call's result and receipt in the mailbox each provide separate evidence. After a mail server accepts sending, check the inbox, spam folder and relevant provider delivery logs. Log mail supports content inspection; actual delivery has its own acceptance step.
- Test submission: record the page, language, form, test label, submission time and admin record identifier.
- Admin verification: check the site, contact details, request, notification state and the follow-up person's access scope.
- Inbox verification: find the matching content and identifier in the dedicated test inbox and record arrival. Ask the maintainer to investigate notification and transport settings for exceptions.
- Production verification: after launch, submit one clearly labelled test enquiry at an approved time. The live follow-up owner confirms the record and email, then marks the test record as agreed.
Recheck fields, CAPTCHA, the honeypot and IP limits against the actual configuration. On a phone, verify entry, validation errors and success messages. See the business website enquiry form guide. Attach each test outcome to its environment and retain the live-domain results separately.
5. Repeat SEO and bilingual journey checks on the live domain
The release owner first checks DNS, HTTPS, application binding and cache updates. Using an ordinary visitor session, open the Chinese and English home pages, listings, details, contact pages and attachments. Apply the following checks to the pages intended for public production access:
- Status and content: verify expected responses, titles, descriptions, the main heading, text, images and attachments against the approved materials.
- Access and indexing: ensure public pages are accessible to visitors and intended crawlers. Remove inherited staging authentication, site-wide robots crawl blocks and
noindex. Inspect response headers from the CDN, proxy and application too. - Canonical addresses: check that each canonical points to the corresponding live URL and language links connect the live Chinese and English pair. Use approved production paths in body links, navigation, images and downloads.
- Discovery resources: inspect production robots and the sitemap for the correct domain, protocol and language paths. Check applicable structured data, Open Graph URLs and actual publication dates.
- Mobile journey: move from a listing to a detail page, switch language, open a resource and reach the enquiry entry. Verify readable text and tables and usable forms.
Keep staging under its preview access controls. Use the CatchCMS SEO output checks for individual pages. After public acceptance, follow the search discovery guide for site verification, sitemap submission and URL inspection. Record publication, search indexing, rankings and citations in AI answers using their respective observed results.
6. How CatchCMS sites relate to separate environments
CatchCMS implements site-scoped content, languages, domains and admin permissions, and its frontend resolves sites by Host. Multiple sites can share an application and runtime resources. System releases, shared code, theme versions and mail transport still require technical coordination. Multiple domains pointing to the same site also read that site's data. During procurement and delivery, list business site scopes and separate application environment resources individually.
Uploading a new version under the same theme name changes the current version used by domains bound to that theme. For independent testing or staged releases, technical staff should first arrange the theme package, bindings or deployment approach. Theme rollback covers templates and assets; database, file and system restoration each need their own procedure. See the theme upgrade and delivery checklist.
Preview protection, resource permissions, test email destinations and release procedures are project deployment and acceptance responsibilities. The APP_ENV name is one configuration value. Verify actual resource connections, responses and operation results. For automatic staging creation, one-click synchronization or automatic rollback requirements, ask the provider to demonstrate the implementation in the agreed release and confirm its scope.
7. A clearly labelled rehearsal example
Fictional example: an equipment company plans to add an English manual to its PX-100 product page and upgrade the theme. Technical staff prepare a separate staging application with restricted access, an independent database and file location, fictional contact information and a dedicated test inbox. Marketing checks model names, units, attachment versions and content in both languages, then completes an enquiry labelled as a test.
After the rehearsal, both parties approve a release containing the theme changes, English manual and corresponding content fields. They save the current production versions, original values and backups. The release owner deploys the agreed changes and rechecks links, SEO and mobile display on the live Chinese and English product pages. Sales confirms a production test record and notification at the agreed time. If a problem occurs, follow the predefined rollback scope and reconcile real enquiries added during the release. The product, environments and actions here illustrate an acceptance method.
8. Give the register to the person maintaining the site
Use this format for every item: environment | domain and page | resource or configuration location | owner | operation time | expected result | actual result and evidence | open issue and deadline. Retain at least seven groups of results: access controls, data and file isolation, form records, email arrival, live SEO, mobile reading and rollback preparation. Store evidence containing personal data, credentials or internal addresses within its authorized access scope.
Use project consultation to provide hosting, domains, site and language counts, mail and external service connections, maintenance ownership and the proposed release scope. Request confirmation of CatchCMS staging, production deployment and delivery responsibilities against each item. Have the actual maintainer complete a reviewable rehearsal before scheduling the production launch.