How to Secure a Website on a New Host: First 10 Things to Do

Overview

If you want to secure a website on a new host, the goal is not to do everything at once. The goal is to lock down the obvious risks first, verify the essentials, and create a baseline you can maintain. A good new hosting security setup should reduce exposure without breaking email, DNS, logins, or site performance.

The first 10 things to do are:

1. Confirm DNS and hosting access are under the right accounts.
2. Enable SSL and force HTTPS correctly.
3. Change all administrative passwords and review users.
4. Turn on backups and test a restore path.
5. Update the CMS, plugins, themes, and server runtime.
6. Lock down file permissions and unused services.
7. Set up a firewall, bot protection, and login hardening.
8. Verify email-related DNS records and domain settings.
9. Enable monitoring for uptime, SSL expiry, and suspicious changes.
10. Document the setup so future changes do not weaken it.

This order matters. SSL before redirects, backups before major cleanup, and user review before inviting new collaborators will save time and reduce avoidable downtime. If you have recently changed DNS, it also helps to understand propagation behavior before assuming a certificate or redirect is broken. For that, see How Long DNS Propagation Takes and What You Can Do While Waiting.

1) Confirm DNS and hosting access are under the right accounts

Before changing any settings, verify who controls the domain registration, nameservers, DNS zone, hosting panel, and application admin. Many post-migration problems come from split ownership: the site files are on the new host, but DNS still lives somewhere else, and no one is sure who can change it.

Check these items first:

• The domain registrar account is accessible and uses current recovery details.
• You know whether DNS is managed at the registrar, a CDN, or the host.
• Hosting control panel access is restricted to current admins only.
• Old hosting accounts are not still serving live traffic unexpectedly.
• Nameserver and zone records match your intended setup.

If you are still in the handoff stage, this is also a good time to review safe domain and DNS procedures in How to Point a Domain to a New Host Safely and DNS Records Explained: A, CNAME, MX, TXT, NS, and AAAA for Beginners.

2) Enable SSL and force HTTPS correctly

A secure web hosting setup starts with encryption in transit. On a new host, do not assume SSL is fully active just because the host advertises hosting with free SSL or instant SSL hosting. Confirm that the certificate has been issued for the right hostname set: root domain, www, and any live subdomains that need it.

Then verify:

• HTTP redirects cleanly to HTTPS.
• There is no redirect loop between the host, app, or CDN.
• Mixed content warnings are fixed for scripts, images, and CSS.
• The canonical URL in your CMS or application matches the HTTPS version.
• Certificates cover all required domains and subdomains.

If you need to choose the right certificate scope, read Wildcard SSL vs Single-Domain SSL vs Multi-Domain SSL.

3) Change all administrative passwords and review users

After a migration, assume old credentials have been shared more widely than you think. Rotate passwords for the hosting panel, SFTP or SSH users, database users if practical, CMS admins, and any deployment integrations. If your host supports SSH keys, prefer them over password-only access for technical users.

Review every account with access to:

• Your hosting control panel
• WordPress, Drupal, or another CMS admin
• FTP, SFTP, or SSH
• Database management tools
• CDN, DNS, and SSL dashboards

Remove stale users, reduce permissions where possible, and enable two-factor authentication anywhere it is available. A new host is the right moment to stop carrying legacy access forward.

4) Turn on backups and test a restore path

Backups are only useful if they are automatic, recent, and restorable. Many site owners enable website backup hosting features and stop there. The missing step is testing whether a file restore, database restore, or full-site rollback is actually possible within your environment.

At minimum, confirm:

• The backup schedule is active.
• The retention period is long enough for your risk tolerance.
• Backups include both files and databases.
• Off-server or off-account copies exist for important sites.
• You know how to restore to staging or an alternate location.

For a deeper planning model, see Website Backup Strategy for Small Business: What to Back Up and How Often.

5) Update the CMS, plugins, themes, and server runtime

A migration often carries old software forward. That is understandable during cutover, but it should not remain that way for long. Outdated plugins, themes, modules, and unsupported runtime versions are among the most common avoidable risks on both shared hosting and cloud hosting platforms.

Work in this order:

1. Take a fresh backup.
2. Update the core application or CMS.
3. Update extensions, plugins, themes, or modules.
4. Remove anything inactive and unused.
5. Review the server runtime version and upgrade if your app supports it.

If you are on managed WordPress hosting, some of this may be automated, but you still need to verify compatibility and confirm what your host updates for you versus what remains your responsibility.

6) Lock down file permissions and unused services

Not every host exposes the same controls, but every setup benefits from basic housekeeping. File permissions should follow least privilege. Writable directories should be limited to what the application actually needs. Unused services, staging apps, test scripts, import files, and installation leftovers should be removed.

Examples of items worth checking:

• Default admin URLs are protected or limited where possible.
• Directory listing is disabled.
• Configuration files are not web-accessible.
• Old zip archives, database dumps, and export files are removed.
• Unused subdomains, cron jobs, and app instances are deleted.

On cloud VPS or developer hosting, this step may also include reviewing open ports, SSH configuration, sudo access, and which services start automatically on boot.

7) Set up a firewall, bot protection, and login hardening

Even simple sites receive automated login attempts and low-grade probing. A secure web hosting baseline should include some layer of request filtering and brute-force protection. The exact tool varies by host, but the principle is the same: make repetitive abuse more expensive and legitimate access easier to manage.

Useful controls include:

• Web application firewall rules at the host, CDN, or plugin level
• Rate limiting on login and API endpoints
• Two-factor authentication for admin accounts
• CAPTCHA or challenge steps where appropriate
• Login URL hardening, if supported and sensible for your workflow

Be careful not to over-harden admin access without a recovery plan. If you block your own team after a DNS or IP change, the security control becomes an outage risk.

8) Verify email-related DNS records and domain settings

Website migrations often affect more than the website. If DNS moves or gets recreated from scratch, mail delivery can break quietly. That may not sound like a website security issue at first, but failed verification emails, missing password reset messages, and spoofing-prone records all create operational risk.

Double-check:

• MX records still point to the correct mail provider.
• SPF, DKIM, and DMARC records are present if you use business email.
• Contact forms send from approved domains where possible.
• System emails from the site are working after the move.

If the domain itself is also new, you may find it helpful to review Domain Name Registration Checklist for New Businesses.

9) Enable monitoring for uptime, SSL expiry, and suspicious changes

Security is not just prevention. It is also detection. A new host should have at least a lightweight monitoring baseline so you notice certificate failures, downtime, broken redirects, and unexpected content changes before users report them.

A practical minimum set includes:

• Uptime checks for the main site and critical pages
• SSL expiry alerts
• Backup job failure alerts
• Disk usage and resource alerts where supported
• File change or malware scan alerts if your stack offers them

Monitoring also gives context to the host's stated uptime guarantee. For more on that, see What an Uptime Guarantee Really Means in Web Hosting.

10) Document the setup so future changes do not weaken it

The final step is not technical, but it is what makes the checklist reusable. Write down the current setup: where DNS is managed, where backups run, who owns SSL renewals, which plugins are required, and which access methods are approved. Without documentation, future changes during a redesign, emergency fix, or staff turnover often reintroduce the same problems.

Your notes should include:

• Primary domain and subdomain map
• DNS provider and key records
• Hosting panel and recovery contacts
• Backup schedule and restore steps
• Admin user list and approval process
• SSL coverage and renewal method

Checklist by scenario

Different hosting models expose different risks. Use the same 10-step sequence, but emphasize the controls that fit your environment.

Shared hosting plans

On shared hosting, focus on isolation and provider defaults. Confirm SSL is active, remove unused applications, update everything promptly, and rely on the host's easy hosting control panel features for backups, user management, and basic security controls. Because you have less server-level control, housekeeping matters more.

Managed WordPress hosting

On managed WordPress hosting, check what is already handled by the platform and what is not. Core updates, caching, and some malware scanning may be included, but plugin quality, admin user hygiene, form delivery, and domain-level DNS management usually still need your attention. Treat the host's automation as a foundation, not a complete security policy.

Cloud VPS and developer hosting

On VPS hosting for developers, add server baseline checks: open ports, SSH hardening, package updates, service exposure, log review, and least-privilege deploy accounts. This environment offers more flexibility, but it also gives you more ways to leave unnecessary services exposed. If you run containers or custom stacks, document image sources, secret handling, and restart procedures as part of the initial hardening pass.

Sites after domain transfer or DNS change

If your move included a transfer domain process or nameserver change, expect short-term confusion between old and new records. During that window, check SSL issuance, redirects, mail records, and any IP-based allowlists carefully. It may also help to review How to Transfer a Domain Name Without Downtime: Step-by-Step Checklist.

What to double-check

Before you consider the site fully secured on the new host, do one final pass on the items most likely to be missed.

• HTTPS is enforced everywhere: not just the homepage, but admin paths, checkout pages, login screens, and subdomains in active use.
• Backups can be restored: not merely created.
• Old host access is retired: stale users, cron jobs, and duplicate apps are removed.
• DNS records are complete: website, email, verification, and any third-party services still work.
• Logs and alerts are available: so you can investigate issues instead of guessing.
• Performance did not regress: security changes should not create endless redirects, broken caching, or blocked static assets. If speed dropped after hardening, use How to Improve Website Speed on Any Host: A Practical Checklist.
• Subdomains are intentional: test, staging, blog, and app subdomains often get forgotten. If your structure is changing, see Subdomain vs Subdirectory for SEO and Site Management.

Common mistakes

The biggest errors are usually procedural, not exotic attacks. Here are the ones that repeatedly cause trouble after launch or migration.

• Forcing HTTPS before the certificate is valid. This can create warnings or lock users out unnecessarily.
• Keeping old admin users "just in case." Temporary access tends to become permanent.
• Assuming the host handles all security. Even secure web hosting plans have shared responsibility.
• Ignoring email DNS during a website move. Contact forms and account recovery often fail silently.
• Leaving backups untested. A backup that cannot be restored is only a theory.
• Moving too quickly to delete the old host. Verify traffic, media, SSL, cron jobs, and database writes first.
• Skipping documentation. Six months later, no one remembers where the real DNS zone lives.

When to revisit

This checklist is most useful when reused, not read once. Revisit it whenever the underlying inputs change.

Run through the list again:

• After any host migration or major DNS change
• Before seasonal traffic peaks or campaign launches
• After adding a new admin, developer, or contractor
• After enabling a CDN, firewall, or new SSL setup
• After a CMS redesign or plugin overhaul
• When workflows or control panels change
• At least quarterly for business-critical sites

For a practical routine, turn the 10 steps into a recurring onboarding and review document. Assign an owner for each one, note the last review date, and keep links to your hosting panel, DNS dashboard, backup console, and restore instructions in the same place. That small bit of discipline is what turns a one-time migration task into a durable website security checklist.

If you do only three things today, make them these: verify HTTPS, rotate admin access, and test a restore. Those three steps close a surprising number of gaps on a new host and give you a stable foundation for the rest.