To launch a website after coding, deploy its production files to suitable hosting, connect your domain, enable HTTPS and test the live site before announcing it. If the website uses a database, user accounts or payments, you also need production settings, data protection measures and a recovery plan. The aim is not simply to make the homepage load. It is to make the website usable, secure and supportable.

Treat launch as a controlled release rather than a final upload. This checklist follows the order that reduces avoidable rework, whether you are publishing a small business website or preparing a custom application for its first users.

1. Establish what your website needs to run

Start with the project, not a hosting offer. A static website serves HTML, CSS, JavaScript and assets directly to the browser. A dynamic website also runs server-side code, often with a database. Some projects combine a static front end with separate services for forms, accounts or content.

That distinction determines what you deploy. A project with a build step may produce a separate output folder containing the publishable files. Uploading the source folder instead can leave the host without a usable website. A server-rendered application needs its runtime and start process configured, not just its files copied across.

  • Record the language, framework and supported runtime version, plus the commands used to install dependencies, build and start the site.
  • List databases, file storage, scheduled tasks, background workers and external services such as email or payment processing.
  • Identify what must persist between deployments: uploaded images, customer records, orders and editable content should not disappear when code is replaced.

2. Choose hosting and secure the accounts

Choose hosting that supports those requirements. Static hosting suits a site made entirely of generated files. Managed application hosting can reduce server administration, while a virtual server gives more control but leaves someone responsible for operating system updates, configuration and recovery. A content management system needs hosting compatible with its software and database requirements.

Before committing, check how deployments, HTTPS certificates, backups, logs and restores work. Ask what the provider maintains and what remains your responsibility. Hosting support and application support are different: a server can be healthy while your booking form is broken.

Keep the domain, hosting and code repository under accounts the business controls. Enable multi-factor authentication where available, give collaborators individual access and store recovery details securely. Record renewal contacts and billing ownership now, rather than leaving the live site dependent on a contractor's personal account.

3. Prepare a production release

Production is the environment used by real visitors. It should have its own configuration, separate from your laptop and test environment. Set the live domain, database connection, email credentials and external service keys explicitly. Disable public debugging output so errors do not expose internal paths or sensitive details.

Keep secrets out of public files and the code repository. Use the hosting environment's secret configuration facilities where appropriate. Browser-delivered JavaScript is visible to visitors, so putting a private API key in a front-end configuration file does not protect it. Move operations requiring private credentials to a suitable server-side component.

Build from a recorded version of the code and keep the dependency information needed to reproduce it. Prefer a repeatable deployment process over editing live files manually. Even for a small site, you should be able to identify the release, deploy it again and return to the previous version.

4. Test the hosted version before switching traffic

Use a staging environment or temporary hostname to test the website on its intended hosting. Protect staging from public access, particularly if it contains confidential information. An instruction asking search engines not to index a page is not access control. Use sanitised test data rather than copying customer information unnecessarily.

Test complete journeys, including unsuccessful ones. A form displaying a success message does not prove the enquiry reached the intended inbox. A payment returning the customer to a confirmation page does not prove the order was recorded correctly.

  • Check navigation, images and direct links to internal pages. Refresh a nested page to catch routing failures that clicking from the homepage can hide.
  • Submit forms and confirm delivery. Test validation, error messages, spam controls and what happens if a connected service fails.
  • Test mobile layouts, keyboard navigation, visible focus, form labels, text readability and representative browsers.
  • For accounts or transactions, test permissions, password recovery, failed payments and duplicate submissions. Use the payment provider's testing facilities before enabling live transactions.

Check loading behaviour on a slower connection, not just your development machine. Review browser errors and application logs. If replacing an existing website, map valuable old URLs to their new equivalents so bookmarks and search visitors do not arrive at missing pages.

5. Connect the domain without disrupting email

Your domain registrar manages the registration. DNS, the domain name system, directs visitors and other services to their destinations. Your DNS provider may be separate from both the registrar and web host. Establish where the active records are managed before changing anything.

Save the existing DNS configuration, then follow the host's instructions for the website records. Avoid replacing the entire DNS setup simply to connect a new website. Mail routing, email authentication and service verification may rely on records unrelated to web hosting. Changing nameservers without recreating those records can interrupt services beyond the site.

Configure the root domain and www version, choose the preferred address and redirect the other to it. Provision an appropriate TLS certificate, commonly labelled SSL in hosting dashboards, and confirm HTTPS works. Check for mixed content, where an HTTPS page still requests resources over HTTP. DNS caching means different visitors may reach different destinations during a change, so retain the old hosting until the move is validated.

6. Make recovery possible before launch

Back up the data as well as the code. A repository does not normally contain live orders, uploaded files or database content. Define what is backed up, where copies are stored, who can restore them and how much recent activity the business could tolerate losing.

Test a restore into a separate environment before relying on the backup. Also write a rollback plan: what triggers it, who decides and how the previous release is restored. Database changes need particular care because older code may not work with a changed database. Restoring an earlier database after taking real orders could erase those orders.

For an existing transactional website, agree how new records will be handled during migration. A short, planned pause in ordering may be safer than allowing two systems to accept changes independently. This is a sensible point to involve a developer if data migration or recovery is outside your confidence.

7. Launch, verify and assign ongoing support

Choose a launch window when the people needed to fix problems are available. Deploy the approved release, complete any planned data migration and switch the required DNS records. Avoid unrelated changes during this window so faults are easier to isolate.

Repeat critical checks on the final domain from a fresh browser session and another network. Confirm HTTPS, redirects, forms, email delivery and any live transaction flow. Remove launch-only indexing restrictions from public pages, check page titles and canonical URLs, and ensure private areas remain protected. Search indexing is separate from making a website publicly accessible.

Then monitor outcomes, not just availability. An uptime check can show that a page responds while enquiries fail silently. Assign someone to review errors, failed background tasks and important customer journeys. Route alerts to a named person, with an alternative contact and a clear route for urgent faults.

If you need external maintenance, establish responsibility for application updates, backups, restores and fault investigation before choosing a provider. FullyCoded's website maintenance service includes automated daily backups with off-site storage. The team carries out a technical audit before agreeing maintenance for an existing site.

Keep a short handover covering account ownership, deployment steps, backups, renewals and support contacts. Before announcing the website, make sure someone other than its original developer can find those details and use the recovery plan.