The decision for a small business
A launch is more than uploading pages. Owners should check approved content, domain routing, SSL, mobile layout, forms, privacy notices, backups, and the ability to roll back if something breaks.
An illustrative small-business scenario
Consider this hypothetical situation: A site loads after deployment, but a real enquiry never reaches the business. Launch acceptance should test the server and downstream notification, not only visual appearance.
The point is not that every business has the same needs. For website launch checklist: what to review before going live, first identify the real decision, the person responsible and which evidence will show that the selected option worked.
How to plan it
Verify links and both language routes, test enquiry delivery through an authorised test, inspect robot/sitemap settings, record a known-good version and confirm the intended publication destination.
Limits to understand
A successful code build is not proof that real visitors can submit forms or that Google has indexed the site. Record separate source, staging and live verification results.
A practical next decision
Before publishing, check the real pages on mobile and desktop, navigation, forms, domain redirects, HTTPS and public contact details. Compare canonical URLs and sitemap entries with actual 200-response pages. Keep a rollback copy so an attractive homepage does not conceal broken service routes.
Define the launch decision and approvers
A launch is a controlled business decision, not the moment a developer finishes uploading files. Identify the owner who approves customer-facing wording, the technical person who verifies the build, and the person who can stop release if a critical defect appears. Set the intended domain, language versions, service pages and contact channels in a signed-off inventory. Record what is explicitly excluded from this launch, such as untested payment features or unfinished integrations. Keep an evidence list showing which checks were performed, by whom and against which build. A checklist without accountable reviewers is only a reminder, not release approval.
Check every promised service and commercial claim
Read the homepage, service descriptions, enquiry prompts and footer as a prospective customer. Verify that service names, coverage areas, opening hours, guarantees and prices match current owner-approved evidence. Remove placeholder testimonials, invented review scores and claims that a provider performs work outside the agreed scope. Check that links to policies and terms point to the correct approved versions. For a bilingual website, compare the meaning of important commercial statements in both languages rather than relying on matching page lengths. Any unresolved claim should be recorded as a blocker with an owner, not silently left for the launch day.
Review the navigation as a first-time visitor
Start at the homepage without using the editor's internal links. Can a visitor find the relevant service, understand the next action and return to the main navigation? Check header menus, mobile menus, footer links, breadcrumbs where used, and calls to action. Confirm that each menu label describes the destination and that there are no links to unpublished drafts. Open links in an ordinary browser session rather than assuming the build generated them correctly. On long articles, test related links and language switching. Navigation failures can hide valuable content even when every individual page exists and loads successfully.
Validate English and Bahasa Melayu parity
For each important English page, identify its Bahasa Melayu counterpart and confirm the language selector reaches the equivalent topic. Compare phone numbers, contact methods, service boundaries, warnings, prices and dates. An untranslated button or mismatched enquiry destination can confuse customers even if the article body is fluent. Verify that each locale has its own suitable title, description and navigation text. If one language is incomplete, mark that page as not ready rather than filling the gap with repeated generic prose. Keep a translation review record separate from automated word counts; sufficient length is not proof of accurate meaning.
Test forms from submission to staff response
A contact form is only useful when the entire route works. Submit a safe test enquiry from desktop and mobile, including required-field errors and a valid message. Verify the confirmation shown to the visitor and the information received by the responsible mailbox or system. Check that the message includes enough context to reply without exposing unnecessary personal data. Determine what happens if a notification is delayed or rejected. Do not count a green success banner as evidence that staff received the message. Keep test identifiers and outcomes in a QA record, and do not send unsolicited customer communications during testing.
Verify domain routing without changing production
Prepare an inventory of intended hostnames, such as the root domain and the www version, and document which address should be canonical. Review planned DNS, hosting and proxy responsibilities with the authorised administrator. A predeployment source check can validate configuration files and expected links but cannot prove live DNS routing or certificate behaviour. Do not change nameservers, mail records or production proxy settings merely to satisfy a checklist. Schedule controlled live checks only after the owner approves the release window and rollback. A website can render perfectly in a local preview while the public hostname still points elsewhere.
Confirm HTTPS and the correct certificate boundary
Check the intended HTTPS addresses and document where TLS terminates: at a reverse proxy, the origin server or both. A browser padlock does not establish that every backend connection is protected. Cloudflare documentation distinguishes its edge certificates from origin configuration and notes that certificate provisioning depends on setup. For a launch review, inspect source references to HTTPS, avoid mixed-content resources and plan certificate validation at the actual hostname after authorisation. Do not claim certificate issuance or secure transport from a screenshot of a local page. Record expiry monitoring and the person responsible for renewal where relevant.
Inspect redirects and broken destinations
Create a list of old URLs that must continue working after the new site appears. Permanent redirects are suitable for genuinely moved content; temporary redirects have different semantics, as explained by MDN's HTTP guidance. Verify that redirects point to relevant destinations and do not form loops or unnecessary chains. Test internal links for missing pages, incorrect language destinations and accidental references to staging hosts. Include image URLs and downloadable documents, not only navigation links. Do not modify live server rules during an editorial review. Produce a proposed redirect map for the release owner to approve and implement through the authorised deployment process.
Review canonical URLs and language annotations
A page can have a valid title yet send conflicting indexing signals. Inspect the canonical URL selected for each public page and confirm it represents the intended version. For bilingual pages, check that alternate-language references are reciprocal and lead to corresponding content. Avoid accidentally marking every Bahasa Melayu page as canonical to an English page when both versions should be available. Distinguish draft, staging and production addresses in automated output. These checks can be performed against generated HTML before deployment, but actual indexing is decided later by search engines. A clean source audit is not evidence that Google has crawled the site.
Check robots instructions and XML sitemap contents
Review robots instructions for unintended blocking of important public pages. Confirm the XML sitemap contains the intended canonical URLs and does not list private, broken or staging addresses. Google's sitemap documentation explains how sitemaps can be submitted and how problems can be investigated in Search Console; submission does not guarantee indexing. If the site uses image sitemap entries, validate that their referenced files exist and match the page content. Count URLs and associations against the approved source inventory. Never edit production robots files or submit a live sitemap as part of an unapproved predeployment editorial run. Keep those actions for the release stage.
Test responsive layouts at real reading widths
Open representative pages at narrow phone widths, tablet widths and ordinary desktop sizes. Look for clipped navigation, horizontal scrolling, text hidden behind floating buttons and images that cover important wording. Test both languages because Malay and English labels can wrap differently. Check that buttons remain large enough to activate and that a visitor can read the main offer without zooming. Rotate the device and enlarge text to reveal layout weaknesses. Screenshots from a design tool are not a substitute for browser checks against the actual built pages. Record the browser, viewport and affected URL for every defect.
Perform a meaningful accessibility review
Use the W3C WAI preliminary checks as a starting point: page titles, alternative text, headings, contrast, keyboard focus, forms and resize behaviour. Those quick checks are useful but W3C explicitly says they are not a complete accessibility evaluation. Navigate the site without a mouse and confirm focus does not disappear inside menus or dialogs. Make form errors understandable in text rather than relying on colour. Check that decorative images do not announce confusing filenames to screen readers. Assign remediation responsibility and repeat tests after changes. Never label a site fully accessible solely because an automated scanner reported no errors.
Inspect images, logos and asset permissions
Verify that the homepage uses the approved company logo rather than a placeholder or a newly generated imitation. Check favicon references, organisation identity markup and image dimensions against the approved brand assets. Every article illustration should be relevant, readable and supported by appropriate alternative text. Confirm licences or original creation records before publishing photographs and third-party graphics. Test image paths for missing files and ensure compressed formats remain legible on mobile. Do not infer that an image is approved merely because it is present in the repository. Separate asset creation, visual review and final publication authorisation in the release record.
Measure performance without promising a score
A slow homepage may discourage visitors, but performance depends on device, network, server response and the resources loaded. Inspect image sizes, unnecessary scripts, font loading and render-blocking assets before deciding which changes matter. Compare representative pages rather than measuring only the simplest landing page. Use repeatable tools and document whether results came from laboratory simulation or real visitors; these are different evidence types. Do not claim a Core Web Vitals pass without actual measurements. A new design can look lightweight while loading third-party scripts that materially affect responsiveness. Assign a performance budget and verify again after integrations change.
Review privacy notices and data collection
List every form, embedded service, analytics tag and external script that may collect visitor information. Confirm the stated purpose, recipients, retention practice and any required notices against current legal and owner-approved policies. Do not activate optional analytics or advertising tools merely because a template contains their code. Test whether forms expose submitted details in URLs or public logs. Ensure access to enquiries is limited to authorised staff and that backups are handled appropriately. Legal compliance depends on actual processing and current rules, so a generic privacy-page link is not sufficient evidence. Flag uncertain practices for qualified review before launch.
Backups and rollback must be specific
Before replacing any existing site, identify the authoritative source files, configuration, media and any database that would need recovery. Record where a backup is stored, who can access it and how its integrity will be checked. A file named backup is not proof that restoration works. Prepare a rollback decision threshold: for example, widespread contact-form failure or broken customer navigation may justify reverting to the previous known-good release. Define who can authorise that action and how DNS or caching dependencies affect recovery. Do not run a destructive restore during an editorial checkpoint; document the controlled procedure for later release testing.
Confirm build and package safeguards
If the website is generated from structured content, verify that the build reads the intended source files and refuses incomplete required articles. Check that a release archive contains only the approved static output and required assets, not development secrets or unrelated private files. Treat a successful source lint as different from a complete production build. Preserve hard word-count, file-existence and SEO checks rather than weakening them to produce a package quickly. Record the exact commit used for each test so results cannot be attributed to a later revision. If the build fails, investigate the source defect and leave deployment blocked.
Assign final acceptance tests to real people
A developer can verify that pages render, while the business owner must decide whether the content and customer journey are commercially correct. A bilingual reviewer should check meaning and terminology; an authorised technical reviewer should inspect security and operational boundaries. Artwork needs separate visual acceptance. Use a short acceptance record naming the page or feature, expected result, actual evidence, reviewer and date. Never populate a human-review field with an AI-generated claim. Resolve critical defects before approval and distinguish low-priority improvements that can be scheduled later. Publication requires explicit owner authorisation after the complete evidence is available.
Prepare post-launch observation without premature claims
A launch plan should specify who checks public pages, enquiries, certificates and error reports during the agreed observation period. Decide how customers report faults and how the team communicates a rollback if necessary. Search Console may help investigate crawling and sitemap issues after deployment, but indexing and rich-result visibility are not immediate guarantees. Separate a completed offline source check from authenticated browser checks on the live domain. Do not announce success based on a developer preview or simulated metrics. Preserve a dated record of the first authorised public validation and keep unresolved items visible until an accountable person closes them.
Include hosting, domain and application acceptance in the launch sign-off
A website can pass a visual review while its hosting plan is incompatible with the database or scheduled background work. Before launch, map the selected hosting tier to the actual PHP version, extensions, upload paths, cron capability, SSL, backup restoration and process limits. Test the customer journey that matters: a store checkout, a booking confirmation or a school's authorized access to a private report. Record which checks passed in a real environment; a mock test or generated HTML is not proof that production services work.
For OnHypp, the normal Biz/Power email-and-website plans remain the default. Do not treat that allowance as permission to alter a customer's domain registrar or MX records without a reviewed change plan. Before sign-off, ensure the written quotation distinguishes hosting from application installation, maintenance and support. A release must also have the approved rollback and manual deployment gates, not a blind code synchronization.