Launch a website with Hostinger, safely

Start with the operating responsibility

A website builder or managed WordPress path hides much of the server operation so the learner can focus on pages, content and publishing. An empty or custom website path suits code you already control. Migration is a transfer workflow. A VPS is different: it gives operating-system control and makes the owner responsible for updates, services, access, firewall, monitoring and recovery.

Do not choose a VPS merely because it sounds more powerful. Choose it only when the application needs custom services, containers, workers or configuration that the managed surfaces cannot provide.

• Website objective
• Content owner
• Code or CMS source
• Database or uploads
• Required background services
• Named technical operator

Use the onboarding choices as branches

Hostinger's current add-website flow can branch into builder, WordPress, empty or custom website and migration paths depending on the plan and interface. Record which branch you selected and why; later instructions, backup behavior and domain connection steps may differ.

Plan eligibility and included capacity change over time. The course deliberately avoids a permanent pricing or plan-entitlement table: verify current capacity on the official plan and onboarding screen before purchase or upgrade.

Ownership is part of uptime

The business should know which Hostinger account contains the service, who controls its primary email and multifactor authentication, who pays renewals and who can recover access. A domain registered by a freelancer in a personal account is an operational risk even when the website works today.

Record roles and renewal dates without recording passwords, backup codes, authorization codes or reusable verification tokens. Keep emergency access in an approved password manager, not inside a public project note.

• Account owner
• Billing owner
• Domain registrant
• DNS administrator
• Technical operator
• Emergency recovery owner

Find the actual DNS manager

The registrar and DNS manager may be different. Active nameservers determine where the public zone is controlled; editing a familiar hPanel screen does nothing when another provider remains authoritative.

Before connecting a domain, confirm that it is active, that you can change its DNS, and that the intended website is allowed to use it. A domain already associated with another Hostinger account can require ownership verification before it can be attached.

Two actions are easy to confuse

Adding a website creates the project inside the selected hosting plan. Connecting the domain assigns the public name and points traffic toward that project. Treating them as one click makes it harder to diagnose whether a failure is in content, hosting, domain assignment or DNS.

Where the selected flow offers a temporary domain, use it to inspect content and core behavior before moving the public domain. A temporary preview is not final acceptance: canonical URLs, cookies, forms and email still need testing on the real hostname.

Prepare content and data before cutover

For a new site, identify the homepage, legal pages, contact route, owner and release source. For a migration, inventory files, database, uploads, redirects, forms and any scheduled jobs. Preserve a source copy and define whether the old site remains available during DNS propagation.

Do not delete the old website or detach the domain simply because the new hPanel card exists. Release the old path only after the new site, DNS, HTTPS and business functions have passed the acceptance checklist.

• Website exists in the intended plan
• Preview or staging is usable
• Source and data are identified
• Old site remains recoverable
• Cutover owner is named

Nameservers move the whole control point

Changing nameservers can transfer management of the complete DNS zone. Updating selected A, AAAA or CNAME records changes named routes while leaving the DNS authority in place. Use the narrowest method that matches the official website-type guide and the wider system's needs.

Capture the current nameservers and zone before changing anything. Preserve MX, SPF, DKIM, DMARC, verification, subdomain and third-party service records unless the approved change explicitly replaces them.

Propagation is a waiting-and-verification problem

Record the old value, new value, change time and expected destination. Check the authoritative answer and public resolvers before editing again. Multiple hurried changes during propagation erase the evidence needed to identify what is wrong.

Test both the root domain and www behavior, plus any required subdomain. Confirm they reach the intended website and that the canonical redirect is deliberate—not an accidental loop or split destination.

• DNS backup captured
• Website type guide selected
• Email records preserved
• Root and www planned
• Propagation window recorded
• Rollback value available

A mailbox and a connected domain are different states

Create the mailbox in the Emails area, then confirm the domain is connected to the intended mail service. When Hostinger manages the nameservers, its current automatic workflow can add required MX, SPF and DKIM records; when DNS is external, apply the current provider values in the authoritative external zone.

DMARC adds a policy and reporting layer. Avoid publishing copied example addresses or policies without understanding who receives reports and how failures should be handled. Use the values shown for the active account and product.

• Mailbox created
• Domain connected
• MX present
• One coherent SPF record
• DKIM verified
• DMARC decision recorded

Test from outside the garden

Send from the new address to a mailbox at an unrelated provider, then reply. Check sender name, reply address, inbox or spam placement and authentication results. A message between two mailboxes inside the same service is useful, but it does not prove public routing.

Name the password-reset owner, enable available account protection and keep mailbox credentials out of screenshots, tutorials and support tickets. For website forms, use an approved authenticated sending method rather than exposing mailbox credentials in client-side code.

HTTPS is necessary, not sufficient

On current Web and Cloud hosting, Hostinger states that HTTPS is forced by default after an SSL certificate is installed. Still verify the intended root and www hostnames, HTTP-to-HTTPS behavior and certificate coverage in a public browser. Other products, custom certificates and VPS deployments can have different operating steps.

Check for mixed content and redirect loops. A secure padlock proves the connection for that hostname; it does not prove a form, login, database, analytics or email workflow works.

Accept the launch like a real visitor

Test the homepage, a key internal page, contact or signup, and a missing URL on phone and desktop. Confirm the chosen canonical address, readable content, working navigation and a clear success or error state for forms.

Record the exact release or content revision where possible. Define who watches the site after launch and which symptom triggers rollback instead of silent troubleshooting on the live files.

• Root and www behavior
• HTTPS and certificate
• No mixed content
• Core routes
• Form or login
• Phone layout
• 404 or missing route
• Rollback trigger

The product determines the recovery path

Website Builder keeps its own version history and restore workflow. Managed website hosting exposes file and database backups through its website dashboard. VPS backups and snapshots operate at the server level. Do not follow one product's restore instructions on another product.

Availability, retention and downloadable formats can vary by product and plan. Check the active account and current official page instead of relying on a screenshot or a promise copied into a permanent checklist.

• Product type
• Backup location
• Included data
• Excluded data
• Available restore points
• Retention
• Download option

Restoration is a destructive change

A restore can replace newer content, files, databases or an entire server state. Preserve anything created after the chosen recovery point before starting, and understand whether the service locks or becomes unavailable during restoration.

A backup badge is not a recovery plan. Name the acceptable data-loss window, expected outage, restore owner, verification steps and fallback if the chosen restore point fails.

A live site needs an owner after launch day

Assign responsibility for domain and service renewals, content changes, security updates, backup review, mailbox recovery, availability checks and support escalation. Record where release notes and recovery evidence live.

Review the critical public journey after meaningful changes. Do not wait for a customer to discover that the website is secure but its form, payment, login or mailbox no longer works.

Use VPS for an explicit technical reason

A VPS can support custom runtime versions, containers, background workers and private services, but it also creates patching, firewall, access, capacity, logging and incident duties. Require a named operator, SSH-key access, emergency access, a public-port plan, backups and health checks before approval.

Keep databases and internal services private unless there is a reviewed reason to expose them. Test replacement access before removing the only working route, and understand that a full VPS restore can overwrite the current server.

• Renewal calendar
• Content owner
• Technical owner
• Backup review
• Public health check
• Incident contact
• VPS need statement
• Rollback revision