Category: Web Hosting

Secure web hosting services should include a web application firewall, DDoS protection, account isolation, bot protection, free SSL, and automatic backups at no extra cost. Malware cleanup, hourly backups, and advanced scanning are usually paid add-ons. Once you know which group a feature belongs to, any host’s pricing page gets a lot easier to read.

What secure hosting should include by default

Secure hosting should include every protection that runs at the server or network level, because those are the parts of web hosting security you can’t add yourself. A website plugin can’t filter traffic before it reaches the server, and you can’t separate your hosting account from its neighbors on a shared machine. If the plan doesn’t include these, you’re not getting them.

SiteGround runs all of these on every hosting plan as part of its enterprise-grade security system, which runs health checks every 0.5 seconds to spot and fix issues.

Web application firewall (WAF) and account isolation

A web application firewall filters malicious requests before they reach your site, including known attack patterns against WordPress, plugins, and forms. What separates a strong WAF from a basic one is who writes the rules and how fast. 

SiteGround’s security team writes its own WAF rules, including virtual patches for newly disclosed plugin vulnerabilities where possible, which can block an exploit before the plugin’s developer ships a fix. The WAF runs on all servers, and there’s nothing to configure.

Account isolation matters most on shared hosting. It keeps each account’s files and database separate, so a compromised site on the same server can’t read or change yours. SiteGround isolates each account on its servers, on every plan.

DDoS protection

DDoS protection filters floods of fake traffic at the network level, before they overload the server your site runs on. Without it, a relatively small attack can take a site offline for hours, even if nothing on the site itself was hacked. SiteGround includes DDoS protection on all plans.

This included protection covers the baseline. For sites that become direct targets, CDN Premium adds a second layer at the network edge, covered in the paid add-ons below.

AI anti-bot and brute-force protection

Bot protection stops automated login attempts and malicious crawlers before they reach your site. Brute-force attacks don’t need a vulnerability. They just need a login page and a list of common passwords, and bots can cycle through those lists far faster than any person could. 

SiteGround’s AI anti-bot system blocks this traffic at the server level, so it never reaches your WordPress login form and doesn’t eat into your site’s resources.

SSL, auto-updates, and backups: on by default

SSL, automatic updates, and backups should come switched on with any secure hosting plan, not as setup tasks you have to remember. They’re still settings, though, and parts of them can be changed later, sometimes by a developer who meant to change them back. On SiteGround, all three are on from day one and managed in Site Tools. A two-minute check after signing up confirms they’re all set the way you expect.

Free SSL

An SSL certificate encrypts data between the visitor’s browser and your server, which protects logins, forms, and checkout details in transit. It doesn’t protect the site itself: a hacked site with a valid certificate still shows the padlock. When comparing hosts, check whether SSL is free for good or only for the first year, and whether it renews on its own. SiteGround installs free Let’s Encrypt certificates and renews them automatically, so there’s no expiry date to track.

Automatic updates

Automatic updates close known vulnerabilities in WordPress core and plugins before attackers get to them. When comparing hosts, check whether updates run automatically, whether you control their timing, and whether there’s a backup to roll back to if an update breaks something. On SiteGround, the in-house WordPress Autoupdate tool runs from Site Tools > WordPress > Autoupdate, where you set how soon after a new release your site updates and whether plugins update along with WordPress.

Before every update, the tool creates a backup and then emails you to let you know your site has been updated. If anything looks broken when you check it, you can restore the pre-update backup with one click. Premium plugins may not update this way because of their license validation, so it’s worth checking those yourself.

Daily backups

Daily backups give you a clean restore point when something breaks, whether that’s malware, a bad update, or a developer’s mistake. SiteGround creates automatic backups for all sites, keeps up to 30 daily copies on shared hosting, and stores them in geo-distributed locations at no extra charge. You restore them from Site Tools > Security > Backups, without opening a support ticket.

Retention depth matters as much as frequency. If an infection sits undetected for 10 days and your host only keeps seven backups, every restore point is already compromised. That’s one reason daily backups may not be enough for busy stores, which the next section covers.

Common paid add-ons, and when they’re worth it

Paid security add-ons cover detection, cleanup, and faster recovery: the parts of security that happen after something gets through. Paid doesn’t mean optional for everyone. A five-page brochure site and a store taking 50 orders a day need very different coverage. 

Site Scanner, Premium Backups, and CDN Premium are priced per site and ordered from Client Area > Marketplace > Hosting > Additional Services. Expert Care works differently: it’s a monthly subscription with credits you can use across your sites, ordered from Client Area > Services > Expert Care.

Add-on	What it adds	Worth it if	At SiteGround
Malware scanning	Regular file and URL scans, instant alerts	Nobody checks the site regularly, or it runs many plugins	Site Scanner Basic or Premium
Malware cleanup	Automated or hands-on removal	Nobody on the team can clean a hacked site	One-click cleanup with Site Scanner Premium; hands-on cleanup via Expert Care
More frequent backups	Hourly restore points, downloadable copies	A day of lost orders or content is too much	Premium Backups
Edge protection	Attack mode at the CDN, extra caching	The site gets targeted attacks or can’t go down during traffic spikes	CDN Premium

Malware scanning

Malware scanning finds infections early, before visitors, Google, or your customers do. 

What matters is what gets scanned and how often: URL scans catch infections that show up on your public pages, while file scans find malicious code hidden on the server. Daily file scans with instant alerts are the standard to look for.

SiteGround Site Scanner Basic scans your site’s URLs and checks your domain against blacklists every day, runs an automated scan of all your files every week, and lets you run up to 10 full scans a day on demand. It also includes Site Protect, which lets you shut off FTP, SSH, PHP uploads, or PHP shell commands if you suspect someone is trying to get in. Site Scanner Premium moves file scans from weekly to daily, covering subdomains and staging copies, and can quarantine newly uploaded files that look suspicious.

Quarantine is off by default, so turn it on in Site Tools > Security > Site Scanner if your site accepts uploads.

Malware cleanup

Malware cleanup removes an infection once it’s found, and it’s usually the most urgent paid service. Hosts handle it in different ways: some include automated cleanup, some bill per incident, and some leave it to a third-party service. 

At SiteGround, Site Scanner Premium includes one-click cleanup for detected malware. If the automated cleanup can’t fix the issue, SiteGround’s support team reviews the case manually, and an extra cleanup fee may apply. With an Expert Care subscription, a full malware cleanup (code removal, a review of the site, and security recommendations) is one of the tasks you can request using your monthly credits. It’s worth having a plan before you need it, because the steps in cleaning up a hacked site go wrong fast when you’re improvising.

More frequent backups

Daily backups leave up to a day of changes unprotected. For a store, that gap is concrete: restoring a 6 AM backup at 3 PM wipes out every order placed in between. Hourly backups narrow it to under an hour, and downloadable backups give you a copy outside your host’s servers. 

SiteGround’s Premium Backups adds hourly backups, kept for 48 hours, on top of the daily copies, plus seven extra days of daily backups, five more manual backup slots, and downloads for any backup.

CDN-level protection

Included DDoS protection covers the baseline, but a site that becomes a direct target may need protection at the edge of the network, where suspicious visitors are challenged before they reach the server. Hosts usually offer this as part of a premium CDN tier rather than the base plan. 

At SiteGround, it comes with CDN Premium, whose main security feature is Under Attack Mode. You switch it on from Site Tools > Speed > CDN when you suspect a DDoS attack: every visitor sees a short verification page, and any visit that can’t be verified automatically gets a challenge to prove it’s a real person. Under Attack Mode switches itself off after 24 hours, so it’s a tool for riding out an attack, not something you leave on. 

The same plan adds dynamic content caching, CDN coverage for subdomains and parked domains, and a Keep Site Online mode, which makes it worth a look for stores and other sites that can’t afford to go down during a traffic spike.

How to compare secure web hosting services

Compare secure web hosting services by sorting each security feature into three groups: included by default, available as an add-on, or not offered. The headline price only tells you part of the story. Two plans at the same price can land very differently once you add the backups and scanning one of them charges extra for. Use the “What to check” column on any host’s pricing page, and see how SiteGround fills it in:

Feature	What to check	SiteGround
Firewall/WAF	Included on every plan, or only on higher tiers?	✓ In-house WAF on every plan, nothing to configure
DDoS and bot protection	Filtered at the network level, before traffic reaches your site?	✓ DDoS protection and AI anti-bot system
Account isolation	Is your account separated from others on a shared server?	✓ On every plan
SSL	Free for good, or only for the first year?	✓ Free for good, auto-renewed
CDN	Included on every plan	✓ Free CDN; Under Attack Mode with CDN Premium
Automatic updates	Is there a backup to roll back to if an update breaks something?	✓ Backup before every update, one-click restore
Backups	How often, how many copies, and can you restore without a ticket?	✓ Daily: 30 copies on shared, 7 on Cloud, one-click restore; hourly with Premium Backups
Monitoring and reports	Does the host tell you what it’s blocking, without you asking?	✓ Health checks every 0.5 seconds, free Monthly Security Reports
Malware scanning	Daily file scans, and instant alerts when something’s found?	Add-on: Site Scanner, worth adding for stores and client sites
Malware cleanup	Is cleanup included, automated, or billed per incident?	Add-on: one-click cleanup with Site Scanner Premium, or hands-on cleanup via Expert Care
2FA	Available for the hosting account?	✓ For your SiteGround account
Support	Can you reach a person 24/7 during an incident?	✓ 24/7 phone, chat, and tickets

Most sites are well covered by what’s included. Add-ons are there for sites that need more, like a store that can’t afford to lose an afternoon of orders, and they’re added from the same account, with no third-party plugins to install.

Two-factor authentication and access controls

Two-factor authentication should be available for both your hosting account and your site’s admin, because a stolen password is still the easiest way in. On SiteGround, you turn it on for your hosting account from Client Area > Login & Profile. Also check whether you can give developers their own access instead of sharing your login, so you can remove them when the project ends.

Security support

Security support is what your host does when something actually goes wrong, and it’s where plans differ most in the fine print. Ask two things: can you reach support 24/7 during an incident, and which parts of the fix are billed separately? At SiteGround, 24/7 support is included on every plan, while hands-on malware cleanup falls under paid services.

How to spot a paid add-on on a pricing page

Whether a feature is included or extra usually comes down to the wording. Look for these signals on any host’s pricing page:

• “Available,” “optional,” or “add-on” next to a feature, instead of a checkmark.
• “Starting at” pricing in a footnote, which usually means an extra monthly fee.
• Features listed only in the full plan comparison table, not on the main pricing cards.
• Security extras that appear for the first time at checkout. Read what each one covers, and keep only the ones your site needs.

A pricing page won’t tell you everything, though. For the questions to ask a host’s support team, like how fast they patch or how accounts are isolated, the answers show you what’s behind the checkmarks.

How SiteGround compares to other hosts

If you already have a specific host in mind, SiteGround’s head-to-head pages lay out the plan-level differences, from backups to migration: SiteGround vs. Bluehost, SiteGround vs. Hostinger, and SiteGround vs. GoDaddy. And if you’re already planning to leave your current host, the guides to alternatives to Bluehost and alternatives to GoDaddy cover what to look for before you switch.

Choosing a secure web hosting service

When comparing secure web hosting services, start with the protections included in the base plan. A firewall, DDoS protection, account isolation, SSL, and daily backups should be part of your checklist, not unexpected expenses.

Then look at what your website actually needs. A small business website may be well covered by daily backups and the included protections, while an online store may benefit from more frequent backups and malware monitoring. Security is one part of the decision, so weigh it alongside support, speed, and growth room when you choose a web hosting partner. A host that can’t tell you which column a feature belongs in has already answered the question.

Every SiteGround plan comes with its core security protections switched on, from the in-house WAF to geo-distributed daily backups. There’s nothing to install and nothing to configure: the protections run from the moment your site goes live.

As your site grows, optional services add extra coverage when you need it. Explore SiteGround’s hosting plans to compare what’s included and what you can add along the way.

[86]

Frequently asked questions about web hosting security

Every cPanel alternative falls into one of two camps: a self-hosted panel you install and run on your own server, like CloudPanel, Plesk, or DirectAdmin, or a panel your host builds into its plans, like SiteGround’s Site Tools. The right choice comes down less to features than to how much server work you want to take on. This guide walks through both options, how they compare with cPanel, and how to decide which one fits your setup.

Why people move away from cPanel

People leave cPanel for three main reasons: rising license costs, a cluttered interface, and the hope that a new panel will make their site faster. The first two hold up, but that third one needs a closer look. Let’s unpack.

1. Rising license costs

In 2019, cPanel moved from flat server licenses to pricing based on the number of accounts on each server. For hosting companies running thousands of accounts per server, that changed the math overnight, and many passed at least part of the increase on to customers.

Panel licensing is one line item in your overall hosting costs, and it’s built into your plan’s price whether you use the panel or not. On a basic shared plan, that share is usually small. It grows as your site does: once you move up to a plan with your own server resources, cPanel’s per-account pricing can make the licensing cost as much as the server itself. And that cost multiplies if you run multiple servers.

2. A cluttered interface

A standard cPanel dashboard groups dozens of tools into sections like Files, Databases, Domains, Email, Metrics, Security, and Software. That’s useful for power users and server admins. But it’s a lot for non-technical users, like a small business owner who logs in to add an email account or change a PHP version.

For those users, the clutter shows up in three ways:

• It’s hard to tell what matters: Most of the tools on screen are ones you’ll never need, and it isn’t obvious which ones are safe to ignore.
• Every host’s cPanel looks different: Hosts add their own branding, plugins, and upsell banners, so tutorials often don’t match what’s on your screen.
• Everyday tasks are scattered: Caching and staging usually live in separate plugins or third-party add-ons rather than in one place.

3. Performance depends on the host, not the panel

This is the reason that needs some untangling, because a web hosting control panel is simply a management screen. Page speed, on the other hand, comes from what sits underneath it: the web server (Apache, Nginx, LiteSpeed), the PHP setup, and the host’s caching layer.

That cuts both ways. A site on a well-tuned cPanel server can be fast, and a site on a fancy new panel can still crawl on an overloaded server.

Where a built-in panel helps is with convenience. The host’s speed tools are already set up, so caching is on from day one, and extras like Memcached take one click instead of hunting for a plugin that needs to be set up.

The best cPanel alternatives

The best cPanel alternative for you depends largely on one thing: do you run your own server? If you rent a VPS (a virtual private server, meaning your own reserved slice of a physical server) or a dedicated server, you need a self-hosted panel.

If you’d rather not manage a server at all, you’re choosing a hosting plan instead. Many plans still come with cPanel, so if you’re trying to avoid that interface, look for a host that builds its own panel.

Here’s how the options compare at a glance.

Panel	Type	Cost model	Runs on	Best for
Plesk	Self-hosted	Licensed per server, with editions capped by number of domains	Linux and Windows Server	Agencies that need Windows support or many WordPress sites
DirectAdmin	Self-hosted	Licensed per server, tiered by number of accounts	Linux only	Hosts and resellers leaving cPanel for a lighter panel
CloudPanel	Self-hosted	Free	Debian and Ubuntu	Developers running PHP apps on one VPS
Webuzo	Self-hosted	Licensed per server, tiered by number of accounts	Linux (Ubuntu, AlmaLinux, Rocky Linux, Debian, and others)	Small hosts wanting a cPanel-style multi-user setup
OpenPanel	Self-hosted	Free Community edition for personal use; paid Enterprise license per server for commercial hosting	Linux	Personal projects, or hosts that want isolated accounts
Managed server platforms	Managed	Monthly fee per server, plus the cost of the server	A cloud server you rent	Developers and agencies who want their own server without the maintenance
Site Tools	Built-in	Included with SiteGround hosting	SiteGround’s servers only	Site owners who don’t want to manage a server, and who want an easy panel interface

Panel details are as of October 2026. Check each vendor’s website for current pricing, supported systems, and features.

Self-hosted panels: for your own server

These five panels run on a self-managed server. You install them, handle regular updates, and own anything that breaks.

Plesk

Plesk is one of cPanel’s best-known commercial rivals and the only panel here that runs on Windows Server as well as Linux.

• Cost model: Licensed per server, with higher editions adding more domains and features.
• Runs on: Linux distributions and Windows Server.
• Web server stack: Apache with Nginx as a reverse proxy on Linux, IIS on Windows.
• Best for: Agencies managing many WordPress sites that want a built-in WordPress toolkit.
• Watch out for: Paid extensions add up, so the real cost is often higher than the base license.

DirectAdmin

DirectAdmin is the panel many smaller hosts moved to after cPanel’s pricing change. It’s lighter on server resources and keeps a familiar account-based structure.

• Cost model: Licensed per server, tiered by number of accounts.
• Runs on: Linux only (no Windows support).
• Web server stack: Apache, Nginx, LiteSpeed, or OpenLiteSpeed, set through its CustomBuild tool.
• Best for: Hosts and resellers who want cPanel-style accounts for less money.
• Watch out for: The interface is plainer, with fewer one-click extras out of the box.

CloudPanel

CloudPanel is a free panel built for speed on a single server. It skips email and reseller features to stay lean.

• Cost model: Free.
• Runs on: Debian and Ubuntu.
• Web server stack: Nginx with PHP-FPM.
• Best for: A developer running PHP apps or WordPress sites on one VPS from a cloud provider.
• Watch out for: It has no built-in mail server, so you’ll need a separate email service.

Webuzo

Webuzo comes from the team behind the Softaculous app installer, so one-click app installs are built in from day one.

• Cost model: Licensed per server, tiered by number of accounts, with a 15-day free trial.
• Runs on: Ubuntu, AlmaLinux, Rocky Linux, Debian, and other Linux distributions.
• Web server stack: Apache, Nginx, LiteSpeed, or OpenLiteSpeed.
• Best for: Small hosts that want a multi-user, cPanel-like layout with app installs baked in.
• Watch out for: Its community and documentation are smaller than cPanel’s or Plesk’s, so troubleshooting takes longer.

OpenPanel

OpenPanel is the newest option here. It gives each user an isolated container, so one client’s runaway site can’t drag down another’s.

• Cost model: The Community edition is free for personal, non-commercial use (up to 3 user accounts and 50 websites). Commercial hosting needs the paid Enterprise license, priced per server.
• Runs on: Linux.
• Web server stack: Each user account gets its own web server: Nginx, Apache, OpenLiteSpeed, or OpenResty.
• Best for: Personal projects on the free edition, or hosts on Enterprise who need strong separation between client accounts.
• Watch out for: It’s a young project, so expect fewer integrations and a shorter track record.

Managed server platforms

If you want your own server but not the admin work, a managed server platform sits in between. It connects to a server you rent from a cloud provider and handles the panel, security patches, and server setup for you.

• Cost model: A monthly fee per server, on top of what you pay for the server itself.
• Best for: Developers and agencies who want their own cloud server without doing the maintenance.
• Watch out for: You pay two bills, and choosing and sizing the server is still up to you.

Built-in panels: no server to manage

Every option above still means running a server yourself or paying someone to run it for you. Several hosting companies skip that entirely by building their own panel, with nothing for you to install, license, or patch. These panels differ from host to host, so we’ll use SiteGround’s Site Tools as the example.

Site Tools

SiteGround built Site Tools after years of adding its own features on top of cPanel, and by March 2021 it had moved more than a million live sites over.

• Cost model: Included with every SiteGround hosting plan, with no separate panel fee. That also applies if you outgrow shared hosting: SiteGround Cloud Hosting gives you dedicated server resources without managing the server, and its plans include unlimited websites, so adding a site doesn’t add a license cost.
• Runs on: SiteGround’s servers.
• Best for: Site owners who don’t want to manage a server and want an easy panel interface.
• Watch out for: It only works with SiteGround, so switching hosts later means learning a new panel.

How to pick the right cPanel alternative for your setup

The right cPanel alternative depends on one question: who do you want maintaining the server? Answer that, and the shortlist shrinks to one or two options.

Use this checklist to match your situation:

• You run your own server and want a free panel: Start with CloudPanel for a single site or app, or OpenPanel’s Community edition for a few personal projects.
• You need Windows or manage dozens of WordPress sites: Plesk is the only option here with Windows support and a full WordPress toolkit.
• You run a small hosting or reseller business: DirectAdmin or Webuzo give you cPanel-style accounts, usually for less than cPanel.
• You want your own server without the admin work: A managed server platform handles patches and setup on a server you still own.
• You don’t want to manage a server at all: A hosting plan with a built-in panel, like Site Tools, is the most beginner-friendly option and takes the panel off your to-do list entirely.

If you’re unsure which side you’re on, compare managed vs unmanaged hosting first. Because a self-hosted panel only makes sense if you’re ready to own updates, backups, and security fixes at 2 a.m. when something breaks.

Here’s a quick sanity check before you commit:

1. Count the sites you’ll host. One site rarely justifies a licensed panel.
2. Check whether you need email on the same server. If you do, rule out CloudPanel.
3. Price the full stack (server, panel license, backups, and your own time) before comparing against a hosting plan. 

If you’re on the fence about any of those questions, then your situation is probably better suited for a hosting plan with a built-in panel.

Site Tools vs cPanel: key differences

If the checklist pointed you toward a built-in panel, the next question is how it compares with the cPanel you already know. The biggest difference is who builds the panel. Hosts license cPanel from a third party and add their own tweaks, while Site Tools is built and maintained by SiteGround, the company that runs the servers.

That shows up in how the panel looks, what’s built in, and what happens if you switch hosts. Here’s what changes for you day to day:

	cPanel	Site Tools
Who builds it	Licensed from cPanel, then customized by each host	Built by SiteGround for its own servers
Layout	Looks different at every host, often with extra add-ons	Same layout on every SiteGround plan
Speed and caching	Depends on the host’s server setup and any caching plugins or add-ons it offers.	Built-in caching, on by default
Security	Depends on what your host includes	Free SSL and daily backups included
WordPress	Usually installed through an app installer like Softaculous	Install and updates in one menu, plus staging on GrowBig and higher plans
Cost	License cost built into your plan price	No panel fee on any plan
Running several sites	Extra sites are added under one main account	Each site gets its own separate panel
Switching hosts	Works at many hosts	Only works with SiteGround

Two of these differences deserve a closer look:

• Finding things: Familiar cPanel tools still exist in Site Tools under new names. File Manager sits under Site > File Manager, and PHP versions are set in Devs > PHP Manager. You can click through the panel yourself in the free Site Tools demo.
• Security defaults: Site Tools turns on free SSL and daily backups without extra setup, which covers several of the basic website security habits you’d otherwise configure yourself.

Leaving cPanel doesn’t mean starting over

Whichever kind of cPanel alternative you choose, it comes back to the question you started with: how much server work do you want to own? If you’re comfortable running a server, a self-hosted panel gives you full control and plenty of options, including free ones. If you’d rather not, a built-in panel takes that work off your plate, and moving your site is easier than it sounds.

SiteGround has moved more than a million sites to Site Tools, and its team can migrate yours for you, or you can move a WordPress site with the free SiteGround Migrator plugin. SiteGround Web Hosting includes Site Tools on every plan, with caching, free SSL, and daily backups already set up, so there’s no panel license line in your renewal.

[86]

Frequently asked questions about cPanel alternatives

GitHub deployment turns a push into a live update. You push to a chosen branch, a build runs on GitHub Actions or on your host, and the result replaces the version your visitors see. GitHub starts the process. Your host keeps the application running.

What actually happens when you push

Pressing push feels like the last step. With auto-deploy, it is the second step of a six-step pipeline:

1. Commit. You save a snapshot of your changes in your local Git repository.
2. Push. The commit travels to GitHub, and the branch there now points at it.
3. Trigger. GitHub announces that the branch changed, often through a webhook, and whatever is listening reacts.
4. Build. A fresh copy of the code is fetched, dependencies are installed, and the build command runs.
5. Deploy. The build output is moved to where the server runs it.
6. Live. The application restarts on the new version.

From step 3, there are two ways this can go, depending on who runs the build: a GitHub Actions workflow on GitHub’s machines, or your host itself.

From commit to build

A build turns the code you wrote into code a server can run. Your repository holds source files, such as TypeScript, JSX, and a package.json that names dependencies without containing them. The build fetches a clean copy of the commit, installs those dependencies, and runs the build command, which compiles and bundles everything into an output folder. The build runs on either a GitHub Actions runner or your host’s own server, depending on which model you use.

Because the build starts from exactly what is in the repository, “it works on my machine” stops working as an excuse. A file you never committed, or a package you installed globally and never declared, is simply not there.

From build to live

If GitHub ran the build, a workflow step copies the output to your server. If your host ran it, the output is already where it needs to be. Deployment puts the build output, called an artifact, where the server runs it, then restarts the application on the new code. The careful method prepares the new version alongside the running one and switches over only once it is complete, so visitors never see a mix of both. The careless method overwrites live files one at a time, which is what a manual FTP upload does. On SiteGround Node.js Projects, every deploy creates a brand-new build, and older builds stay on the account until you delete them.

Environments: Why staging and production are separate

An environment is a named destination for your code, such as staging or production, with its own settings and secrets. Production is what visitors use. Staging runs the same code against test data, with a test database and a sandbox payment key, so a broken checkout charges nobody.

On GitHub, an environment is also a gate. GitHub’s documentation lists four types of deployment protection rules: required reviewers who approve the job, a wait timer that delays it, limits on which branches and tags can deploy, and custom rules checked by an outside service. Environment secrets are released only to jobs that target that environment, and only after approval when reviewers are required. GitHub also records deployments per environment, so the repository shows which commit is live where. These rules apply to GitHub Actions workflows. If your host deploys through its own GitHub App, protection rules don’t gate that deploy, and staging is something the host provides, or doesn’t.

CI, CD, and the words nobody defines

CI/CD is the umbrella term for automating everything between a commit and a release. It covers three practices, and “CD” means two different things depending on who is talking.

Continuous integration vs. continuous delivery vs. continuous deployment

• Continuous integration (CI) merges changes into a shared branch often and runs an automated build and tests on every one, so a problem surfaces at the commit that caused it.
• Continuous delivery automatically prepares every change that passes for release, but a person decides when it goes to production.
• Continuous deployment removes that decision. Every change that passes goes live on its own.

A host that rebuilds on every push to a linked branch is doing continuous deployment, even if no tests run. Putting tests in front of it is what makes it CI/CD. For the rest of the vocabulary, from pipelines to runners, see our vibe coding glossary.

What GitHub Actions does, and what it doesn’t

GitHub Actions runs your deployment process. It does not host your application. That one distinction clears up most confusion about GitHub deployment.

You describe a workflow in a YAML file in your repository’s .github/workflows folder, name the event that starts it, such as a push to main, and list the steps. GitHub starts a runner, a temporary virtual machine, which checks out your code, installs, tests, builds, and, if you wrote a step for it, sends the result to a server. When the job finishes, GitHub discards the runner.

Nothing from the run stays running, so a GitHub Actions deployment always has two halves: the workflow GitHub runs and a destination you provide, whether a cloud platform, a virtual server, or a hosting account. If that destination can build the code itself after a push, you may not need a workflow at all. When you do, GitHub’s deployment documentation covers the syntax.

Deploying to your own server or host

Deploying from GitHub to a server means connecting a repository to the machine that runs the application, so each push becomes a new live version. The two common approaches differ in who does the build.

Connecting a repository to a web host

• GitHub Actions pushes to the server. The workflow builds on a runner, then copies the result to your server over SSH, using credentials stored as encrypted repository secrets. You maintain the workflow, the keys, and whatever keeps the app running.
• The host pulls from GitHub. You authorize the host’s GitHub App once, pick a repository and branch, and the host builds and deploys every push on its own machines. There is no workflow to maintain.

SiteGround Node.js Projects take the second route. On the GrowBig, GoGeek, and Cloud plans, you connect a repository through the SiteGround GitHub App when you create a Node.js project, and every push to the linked branch rebuilds and redeploys the app. The branch, Node.js version, build command, and environment variables are adjustable in Site Tools, and auto-deploy can be paused without disconnecting the repository. Whether a shared plan suits your app is a separate question, covered in does shared hosting support Node.js.

Why GitHub Pages isn’t the same thing

GitHub Pages is a static site hosting service. According to GitHub’s documentation, it publishes HTML, CSS, and JavaScript files from a repository and serves them as they are. There is no Node.js process, no database, and nowhere for an API route to run. A portfolio or a documentation site suits it. An Express server or anything with a user login does not.

GitHub’s usage limits also state that Pages is not intended as free hosting for an online business, an ecommerce site, or commercial SaaS, and as of October 2026 they cap published sites at 1 GB. 

When a deploy fails

Most failures fall into one of two categories, and each is fixed in a different place, so work out which one you have first.

Failed build vs. failed deploy

	Failed build	Failed deploy
What stopped	The install or build command	The app, after a successful build
What visitors see	Usually the previous version	Errors, if the platform switched before checking
Typical causes	Missing dependency, syntax error, wrong Node.js version	Missing environment variable, hardcoded port, crash on startup

A failed build is the safer failure: on a platform that switches versions only after a successful build, the old version keeps serving. A failed deploy can take the site down if the platform switches before confirming the new version starts. Hosts that copy files into the live folder add a third case, the partial deploy, where an interrupted upload leaves old and new files mixed, and the fix is a full redeploy.

Reading a deployment log

A deployment log is the transcript of every command the build ran, in order. Read it from the bottom up to find where it stopped, then look for the first error above that point, because the final lines usually report the consequence rather than the cause. Lines starting with + or > mark the command being run, and an exit status of 0 means it succeeded.

Warnings are where beginners go wrong, and a SiteGround Node.js test deployment we ran in September 2026 shows why. Midway through the install, npm printed a deprecation notice that reads like a problem. The build carried on and finished with a status of completed:

+ [...] npm install [...]

npm warn deprecated recharts@2.15.4: 1.x and 2.x branches are no longer active. [...]

+ [...] npm run build [...]

> vite build

+ exit 0

Build info: {"status":"completed"}

On SiteGround Node.js Projects, every build is listed in Site Tools > Node.js > Logs with its author, branch, status, and commit, and a Failed tab isolates the broken ones. Open a build’s Actions menu and select View build log, as described in how to manage a Node.js project in Site Tools.

Rolling back

Rolling back means returning production to the last version that worked. With push-to-deploy, the reliable method is git revert: it creates a new commit that undoes the bad one, and pushing it runs a normal build that puts the previous code live again. Avoid resetting the branch and force-pushing, which erases the record of what happened. Remember that a rollback restores code, not data, so database changes the bad release made stay in place. 

On SiteGround Node.js Projects, older builds on the Logs page can be viewed or deleted but not reactivated, so reverting and pushing is how you roll back. 

Is auto-deploy worth it for a small project?

For most projects with a build step, yes. For a static page you touch twice a year, no, and a manual upload is fine.

Auto-deploy pays off when changes are frequent, when the project must be built before it runs, or when more than one person ships code. That includes most apps built with vibe coding tools, where push-to-deploy becomes the final step of the vibe coding workflow. The cost is up front: the project has to live in Git and on GitHub, and if your host does not build for you, you also need a workflow, SSH keys, and secrets. For someone new to Git, learning it is the real price, and it is worth paying anyway.

	Manual upload	Push-to-deploy
How a change goes live	Build locally, connect, upload	Push to the linked branch
During the update	Visitors can hit half-uploaded files	The switch happens once the build is ready
Record of releases	None, unless you keep one	Every deploy tied to a commit
Rolling back	Find and re-upload old files	Revert the commit and push
Best for	A few static files edited rarely	Anything with a build step or regular changes

Putting GitHub deployment to work

GitHub deployment comes down to one chain: push, trigger, build, deploy, live. Once you can name each link, a failed build becomes a log to read rather than a mystery. If your next project is a Node.js app, SiteGround Web Hosting runs Node.js projects from the GrowBig plan upward with GitHub auto-deploy built in, so the host handles the build. If it is an API, hosting a Node.js API backend picks up from here, and if you are still deciding where any project should live, start with how to host a website. 

[86]

Frequently asked questions about GitHub deployment

An API backend needs less from a host than the market implies: a process that stays up, a database, secrets storage, a deploy path, and TLS. Most managed platforms can do all five.

A Node.js API backend is a long-running process that answers HTTP requests and returns JSON. It does not need a dedicated server, a container orchestrator, or a platform priced per instance. It needs somewhere that keeps the process alive, gives it a database and a domain, and redeploys it when the code changes. Node.js server hosting on a managed shared plan covers that, provided you know where the ceiling is.

What an API backend actually needs from a host

Strip away the marketing and an API backend has a short requirements list. Check your own service against it before you compare providers, because most of the differences between hosting products sit above this line, not below it.

• A process that stays up. Your API starts once and answers every request from memory. Something has to restart it when it exits.
• A database it can reach. Usually relational, usually on the same network, ideally not a separate subscription.
• Somewhere to put secrets. API keys and connection strings belong in the host’s environment settings, never committed alongside your code.
• A deploy path you will actually use. If shipping a change is tedious, you will ship fewer of them.
• TLS on a domain you control. Mobile clients will not talk to an untrusted certificate, and most will not talk to plain HTTP at all.
• Logs when a deploy fails. Build output you can read is the difference between a five-minute fix and an afternoon.

Notice what is missing. Horizontal autoscaling, container control, and a private network are real requirements for some services. However, for many early-stage mobile apps, those capabilities are headroom rather than baseline requirements, so paying for them before the workload demands them can add unnecessary cost and operational complexity.

What “API hosting” actually means

The phrase covers three different products, and search results mix them freely. Knowing which one you are being sold saves a lot of wasted evaluation time.

API hosting compared with API gateways and API management

API hosting is application hosting. The provider runs your code as a live process and routes traffic to it. This is what you need if you have written an Express, Fastify, NestJS, or Koa service and it has to exist somewhere.

An API gateway sits in front of an API that already exists. It handles routing, rate limiting, authentication, and request transformation. A gateway does not run your code, and buying one when you needed hosting leaves you with a very capable front door and nothing behind it.

API management is the commercial layer on top: developer portals, usage plans, billing, and analytics for APIs you expose to third parties. It matters when your API is the product. It is irrelevant when your API exists to serve your own front end.

For most teams shipping a mobile app or an internal tool, the answer is the first one, and the other two are problems for a later year.

Where an API backend can live

Four models can run a Node.js API. They differ less in capability than in how much of the operational work they hand back to you.

Application platforms

Platforms built specifically to run application code give you the most headroom: horizontal scaling, WebSocket support, container-level control, and regional deployment. They are the correct answer for a service with real concurrency demands or persistent connections. The trade is that pricing is metered, the database is usually a separate product, and a domain, mailboxes, and backups are yours to arrange. 

Managed shared hosting

A managed shared plan runs your Node.js application as a supervised process alongside the rest of your hosting account. You get a fixed monthly price, a database, a domain, and email in the same place. The control panel covers the deployment, and the familiar hosting tools sit underneath it: a file manager, scheduled jobs, and SSH access to your own account. What you do not get is a server to administer. For a request-response API that is mostly upside, because there is less to configure and less to leave misconfigured.

A VPS

A virtual private server gives you root, and with it every decision: the operating system, the process manager, the reverse proxy, the certificates, and the patching schedule. Choose it when you genuinely need that control. Choosing it by default means you have taken on a systems administration job in order to host a JSON endpoint.

Serverless functions

Functions suit spiky, short-lived work: webhook handlers, scheduled jobs, image processing. They suit a conventional REST API less well, because a persistent database connection, an ORM, and a per-invocation execution model fight each other. Many teams that start an API on functions migrate it to a long-running process within a year.

Model	You operate	Best fit for an API backend
Application platform	The app, and the services you attach to it	High concurrency, WebSockets, regional scaling
Managed shared hosting	The app only	Request-response APIs alongside other sites
VPS	The app, the server, and the stack	Custom system requirements, full control
Serverless functions	Individual functions	Event-driven and scheduled work

What it actually costs to host an API backend

The advertised price of an application platform is rarely the amount you pay. Work out the total before comparing, because the shape of the bill differs more than the headline figure.

What free tiers cost you in cold starts and sleep

Free and entry tiers on most application platforms suspend an idle process. The next request has to wait for it to start again, and that wait is measured in seconds rather than milliseconds. On a web page it reads as slow. On a mobile client with a timeout it reads as a failure, and your user sees an error rather than a spinner. This is the cost that never appears on a pricing page, and it is worth measuring on any host you are considering: deploy something, leave it alone for an hour, then time the first request yourself. 

What you pay for on a metered platform once the database is added 

Metered platforms bill the running instance, then bill separately for the parts an API needs anyway. A managed database is typically its own line item. A custom domain has to be bought elsewhere. Mailboxes on that domain are usually not offered at all. Egress and build minutes may be metered on top. None of this is hidden, but it is easy to compare an instance price against a hosting plan price and conclude the platform is cheaper. 

What a fixed-price plan covers

A shared hosting plan bundles the pieces. The database, the domain, email on that domain, TLS, daily backups, and a WAF come with the plan rather than alongside it, and the price does not move with traffic. For an API that serves a mobile app with a few thousand users, predictable beats elastic. The ceiling is real, but you reach it later than most people expect, and you reach it knowing exactly what the next tier costs.

When a shared plan is the wrong home for your API

This is the section most hosting comparisons skip. A managed shared plan is a poor choice for several kinds of API, and finding that out after migrating is expensive.

• Your API holds open connections. WebSockets are not supported on any SiteGround plan, because opening a custom port for incoming connections is not permitted. This applies across shared hosting, and we cover what shared plans can and cannot run in more detail separately. Long polling over HTTP and HTTPS is the documented alternative and is adequate for infrequent updates, not for a live feed. 
• You need to operate the live process. You get a build log for every deploy and an HTTP error log for traffic that reaches the app. What you do not get is a managed application log: your own console output is not surfaced in the panel. You can write it to a file and read that over SSH, but if you expect to tail a live process or attach a debugger, a VPS will suit you better.
• Your data store is not relational. MySQL and PostgreSQL are both available. A document store such as MongoDB means connecting to an external managed service and accepting the latency that adds.
• Your traffic is genuinely large or genuinely spiky. A shared plan is a fixed slice of a shared machine. An API under heavy sustained load wants dedicated resources, not a bigger shared allocation. 

Running a Node.js API backend on SiteGround

Which plan your API needs

The StartUp plan does not support Node.js, so availability begins on GrowBig. GrowBig runs up to 5 Node.js projects, GoGeek up to 10, and Cloud is unlimited. Count your projects before you pick a tier, and remember that a staging copy of your API counts as a project of its own. A team running one production API and one staging environment per client reaches the GrowBig limit at two or three clients, which is usually what moves an agency up rather than disk space.

Getting your API deployed

Connect a GitHub repository and every push to the linked branch rebuilds and redeploys the service, which is the path worth using for anything under active development. Uploading an archive works too but has no auto-deploy. The mechanics are the same for any Node.js application and are covered in our guide to Node.js support on shared hosting.

The part specific to an API is the environment settings. Database connection strings, third-party API keys, and signing secrets are configured against the project rather than committed to your repository, which also means a staging deployment can point at a different database without a code change.

The database, and pointing a client at it

MySQL and PostgreSQL are both created and managed from Site Tools. PostgreSQL is the one worth noting, because it is uncommon on shared plans and it means an API written against Postgres with Prisma, TypeORM, or Sequelize deploys without a rewrite or a separate database subscription. MongoDB is not available, so a document-store API connects to an external managed service.

Every project starts on a temporary domain, which is more useful for an API than it sounds. Your mobile or front-end client can point at that endpoint and exercise the real service while DNS for your own domain is still pointing somewhere else. Attach your domain when the client is ready, and the API keeps answering on a certificate you control.

Choose the hosting model your API actually needs 

If your API answers HTTP requests, you can live without WebSockets, and you would rather not be responsible for the server underneath it, SiteGround Web Hosting covers Node.js server hosting from GrowBig upward, with the database, domain, email on that domain, daily backups, and a WAF included rather than bought separately.

The right hosting choice is the simplest one that meets your API’s actual requirements without making you operate infrastructure you do not need.

Frequently asked questions

If you’re comparison-shopping after a GoDaddy renewal jump, add-on fees, or a website builder that hit its ceiling, these six alternatives cover beginners, online sellers, and agencies alike. SiteGround leads the list for combining hosting and a builder, backed by security and performance built in from day one, with the option to add ecommerce, email marketing, or AI-assisted building as your site grows.

Why people look for a GoDaddy alternative

If your renewal price jumped past what you signed up for, your store broke at checkout, or your website builder hit its ceiling, you might be looking for something else entirely.

SSL that isn’t free forever

GoDaddy’s Economy plan includes SSL (Secure Sockets Layer) free for the first year, then charges $119.99 a year after that, one of several ongoing hosting costs worth checking before you commit to a plan.

Most of the alternatives on this list, including SiteGround, include free SSL with no time limit, not just a first-year deal.

Support that’s hard to reach when something breaks

WebsitePlanet’s own testing of GoDaddy alternatives describes a slow, hard-to-reach support experience firsthand; WPBeginner built an entire piece around the same frustration. Support quality is the kind of thing you don’t notice until you need it, and by then it’s too late to shop around. SiteGround offers phone, chat, and ticket support 24/7, not every alternative on this list does, Hostinger, for instance, doesn’t offer phone support at all.

Hosting and a website builder, sold as one thing or two

Hosting and website building are often sold as separate products, adding friction when you’re trying to simplify your setup. Several of the alternatives below solve this directly, bundling a builder into the hosting plan itself rather than treating it as a second purchase.

How we picked these GoDaddy alternatives

Every option on this list met four criteria, the same ones worth applying whenever you’re choosing a web hosting partner:

1. Price transparency: is the renewal rate visible up front, not just the intro deal
2. What’s included by default versus sold as an add-on
3. Migration friction: how much work it takes to actually switch
4. Platform breadth: how much a switcher gets in one account

Provider	Free SSL	WAF	DDoS	Caching & CDN	Uptime	Site creation	Ecommerce	Email marketing
SiteGround	✓ permanent	✓	✓	Automatic, 3-layer + in-house CDN, 170+ edge points	99.9% SLA, with compensation for downtime	Builder, WordPress (plus Coderick AI)	✓ From Sell plan	Add-on, free for 30 days
Hostinger	✓ permanent	✓	✓	Page caching only; CDN on Premium plan+	99.9% guarantee	Builder, WordPress, Horizons AI	✓	Not in base plans; Reach, Unlimited plan and up
Bluehost	✓ permanent	Business tier +	Business tier+	Manual setup; CDN third-party	99.99% guarantee, with a 5% credit if missed	WonderSuite AI, WordPress	WonderCart, higher tiers only	X
DreamHost	✓ permanent	✓	✓	Not on shared plans	100% guarantee (a stated commitment, not an independently tested result)	Liftoff AI, WordPress	Via builder, no dedicated suite	X
HostGator	✓ permanent	✓	✓	Cloudflare CDN included	99.9% guarantee	Builder, WordPress	In builder	Creative Mail
Namecheap	✓ first year only	full Imunify360 on Stellar Business only	✓	Supersonic CDN, free tier capped at 50GB/month	100% guarantee; independent testing measured uptime at 99.2%	AI Website Builder, Sitejet, and EasyWP	X	X

The best GoDaddy alternatives

Six options, each covered on its own merits.

SiteGround: The all-in-one platform pick

Best for: small businesses and growing websites that want more responsive support and a more integrated alternative to GoDaddy, with hosting, security, performance, and site-building included, plus ecommerce and marketing tools you can add as you grow.

Strengths:

• All-in-one platform: hosting and a website builder included, with ecommerce, email marketing, and AI tools available on the same account as your site grows, one login instead of juggling separate providers.
• Daily backups: 30-day history and one-click restore, included on every plan, so if something breaks or gets hacked, you’re not losing weeks of work, and you’re not paying extra for that safety net.
• Free SSL, for good: no renewal fee, included on every plan. GoDaddy’s SSL is free for one year, then $119.99/year after, here it’s free permanently.
• In-house WAF (Web Application Firewall), AI anti-bot protection: included by default, so your site is protected from day one, not just after you notice something’s wrong and go looking for a security add-on. Malware scanning (Site Scanner) is a separate purchase, worth adding if you’re managing client sites or a store.
• Multi-level caching stack: free on every plan, so your site loads fast without needing to buy your way onto a higher tier for it.
• Multiple ways to build your website: the website builder or WordPress, both free with hosting, so you’re not locked into one approach. For AI-generated sites, Coderick AI is available as a separate purchase, and ecommerce (the Sell plan) is a separate purchase too, once you’re ready to sell. Hostinger comes closest to matching this breadth, though its email marketing tool sits behind a higher plan tier.
• Migration performance: 80% of sites moved from GoDaddy to SiteGround load faster on the new host, with an average speed increase of 79.5%; the same pattern shows up moving from Hostinger (78% faster, 95% average increase) and Bluehost (84% faster, 75% average increase).

Trade-off: This breadth costs more than picking the cheapest bare-bones plan on this list, though the gap narrows once you factor in what several of those cheaper options charge extra for instead.

Bluehost

Best for: beginners who want a straightforward first website.

Strengths:

• WordPress.org’s long-standing recommendation: Bluehost has been an official recommended host for years, which means a well-worn path, with plenty of tutorials and community support if you get stuck.
• WonderSuite AI builder: a guided, AI-assisted setup that means you spend less time staring at a blank page deciding where to start.
• Included security: weekly backups, malware scanning, and automatic malware removal come standard on every plan. The web application firewall and DDoS protection, paired with AI-powered threat detection, are included from the Business tier up.

Trade-off: ecommerce (WonderCart) is gated to higher-tier plans, and there’s no dedicated email marketing tool if you outgrow a basic inbox.

Hostinger

Best for: switchers who want a similar mix of hosting, builder, ecommerce, and email marketing tools, at a lower entry price. Ecommerce is included from the entry plan; email marketing requires stepping up to the next tier. Email accounts on Hostinger’s entry plan are capped at 2 mailboxes, and its CDN isn’t included on the first tier either, both worth checking if you’re used to having more room to grow before hitting a wall.

Strengths:

• Horizons AI app builder: generates a working site from a prompt, a genuine alternative to a traditional builder if you want something built fast without learning WordPress first.
• Ecommerce and Hostinger Reach: built-in store tools and email marketing, the closest match to SiteGround’s all-in-one setup on this list.
• Free SSL and WAF included: security basics covered without an add-on.
• NVMe (Non-Volatile Memory Express) storage across plans: consistent performance regardless of tier.

Trade-off: email marketing requires stepping up a tier; the entry plan’s mailbox and CDN limits are also worth checking before committing.

DreamHost

Best for: reliability-focused switchers who want backups handled without thinking about it.

Strengths:

• Daily backups on every plan: no tier-gating, the one thing GoDaddy charges extra for, here included by default even on the cheapest plan.
• WAF and DDoS protection: included on every plan, confirmed directly from DreamHost’s own documentation.
• Liftoff AI builder: covers the basics of getting a site live without a steep learning curve.
• 25 sites on the entry plan: a real advantage for anyone managing more than one site under one account.

Trade-off: basic malware protection is included, but DreamShield, its more advanced scanning and alert system, is a paid upgrade, the same add-on pattern that pushes people away from GoDaddy in the first place.

HostGator

Best for: switchers who want a familiar, long-time GoDaddy rival with staging built in.

Strengths:

• Staging environments on every tier: normally a higher-tier feature elsewhere, included here even on entry plans.
• Cloudflare CDN (Content Delivery Network) with Argo Routing: included, not sold separately, for faster load times without an upgrade.
• Free SSL and DDoS protection: included as standard, alongside complimentary malware scanning on shared plans.

Trade-off: the entry plan only includes chat support, no phone line. If your site goes down during a busy sales weekend and typing out the problem feels too slow, getting someone on the phone means stepping up a tier first.

Namecheap

Best for: switchers whose main GoDaddy frustration was domain-related upsells rather than hosting performance.

Strengths:

• Low entry pricing: the cheapest way onto this list if budget is the deciding factor.
• Domain-first reputation: transparent registration pricing and management tools, with fewer surprise upsells at the exact point where GoDaddy’s pricing tends to frustrate people most.
• DDoS protection included: standard even at this price point.

Trade-off: no dedicated ecommerce product, so the cheapest plan on this list isn’t a fit if you’re planning to sell online.

How to move your site off GoDaddy

Migration breaks down into four pieces: DNS (Domain Name System), files, domain, and email, the same fundamentals as hosting a website from scratch.

1. Set up email on your new host first. Get it running and confirmed working before touching anything else, so your inbox never goes down mid-move.
2. Update your MX (Mail Exchange) records once the new email is verified, then keep GoDaddy’s email active in parallel until you’re sure everything’s landing correctly.
3. Copy your files and database. Most hosts, including SiteGround, offer a free migration plugin that handles this automatically, so it’s rarely a manual, file-by-file transfer.
4. Point your domain at the new host’s nameservers. DNS propagation is usually a matter of hours, though it can occasionally take up to 48. Your domain doesn’t need to move at the same time as your hosting, you can point it at a new host without a formal transfer, which is worth knowing if you’d rather handle buying or transferring a domain as a separate step later.

If you’re running a store, export your product catalog as a CSV (Comma-Separated Values) too, as an extra safety net alongside the file and database transfer.

Picking the right GoDaddy alternative for your site

Most of the six options above solve the same core complaints. The real question is which platform matches how your site actually gets used.

If you’re a blogger or content creator

Priority is a smooth writing and publishing workflow. SiteGround covers the basics by default, daily backups, an in-house WAF, and AI anti-bot protection, with Site Scanner’s daily malware checks available as an add-on if you want that layer too. Bluehost’s WordPress backing and DreamHost’s included daily backups both make sense here. If you pick DreamHost, remember DreamShield, its advanced malware scanning, costs extra, though basic protection is included.

If you’re selling online

This is where reliability matters as much as features, since a broken checkout costs more than a renewal fee ever could. SiteGround’s ecommerce and email marketing live in the same account as hosting, so there’s nothing extra to piece together as the store grows, no re-platforming, no new tier unlocking a tool you already needed. As sales pick up, the plans scale with the store rather than forcing a switch to a different product entirely.

If you’re an agency managing multiple client sites

Client needs vary, so consistent tooling across sites matters more than any single feature. SiteGround lets you manage every client site from a single dashboard, add team members as collaborators on any site, and, on GoGeek plans and higher, give clients white-label access to their own Site Tools with no SiteGround branding in sight. Speed and security matter more here too: a compromised site reflects on the agency, not just the client.

Storm Design, for instance, a Maltese agency, moved its full portfolio to SiteGround after a hack took 85 sites offline at once. A year later, the agency manages 200+ sites with zero hosting emergencies and zero support calls. Founder Jesmond Darmanin sums up his experience:

“Once I moved to SiteGround, I managed to retain all of the clients I have, and I also managed to get back some of the clients that had complained before.”

If budget is the deciding factor

Even the leanest setup benefits from backups, security, and speed included rather than added on later, since that’s exactly where a tight budget gets squeezed the hardest if something’s missing. SiteGround’s entry plan covers all three by default. A lower sticker price elsewhere is worth weighing only once you know what it doesn’t include.

Breaking up with GoDaddy? Here’s your next move

Whichever of these GoDaddy alternatives fits, the switch itself is rarely as disruptive as it looks once DNS, email, and files are mapped out ahead of time. 

SiteGround stands out on this list mainly because it’s the one place a switcher gets hosting and a website builder included, backed by security and caching that work automatically rather than needing manual setup, with ecommerce, email marketing, and AI tools available on the same account rather than pieced together from separate providers.

[86]

Frequently asked questions about GoDaddy alternatives

Some shared hosts run Node.js. Most still don’t. The difference isn’t the price of the plan, it’s the runtime model: PHP discards your application’s state at the end of every request, while Node keeps one persistent process running and waiting for requests. Supporting Node.js means supervising that process.

Almost every answer you’ll find about Node.js on shared hosting was written before that supervision existed.

What “supports Node.js” actually means

The phrase covers two different things, and conflating them is why forum answers often contradict each other. The first is availability: Node exists on the server and you are free to use it, but starting your application, keeping it alive, and pointing a domain at it are all your problems. The second is execution: the host runs your application for you, as a supervised process that stays up, answers on your domain, and starts again by itself when something goes wrong.

Only the second one is hosting. The first is a toolbox, not a service.

That explains the pattern across the types of web hosting sold as “Node-friendly”. A host can truthfully say Node is installed while offering nothing that keeps your application running. Started by hand, it stops the moment the connection that started it closes, because nothing was ever watching it.

A host that genuinely supports Node.js provides all of the following:

• A process supervisor that starts the app and restarts it if it exits
• A web server in front of the app, mapping your domain to it
• A selectable Node.js runtime version
• A dependency step that installs what your package.json declares, using npm, pnpm, or yarn
• A way for the platform to work out which file boots your app, whether it detects it or you set it
• Environment variable storage outside your repository
• Build and deployment logs you can read when something fails

If a plan description mentions no process manager and no way to deploy an application, it’s offering you a binary, not a runtime.

Why shared hosting was built for PHP, not Node.js

Shared hosting was designed around a request model Node.js doesn’t use. The standard stack puts hundreds of accounts on one machine and stays stable because no single site holds resources between visitors. That assumption is baked into how shared hosting allocates memory, which is why Node needed a separate mechanism rather than a config flag.

How PHP releases your application’s memory after every request

A PHP request has a short, bounded lifecycle. A visitor hits the page, the web server hands it to a worker process that is already running and waiting, the worker loads the script, runs it, returns HTML, and then releases everything that script allocated. The worker itself stays alive and picks up the next request. What gets discarded is your application’s state, not the process holding it. That’s why one server can host hundreds of accounts: only the sites being visited consume anything. The per-request lifecycle in PHP 8.4 is a resource isolation strategy as much as an execution one.

Node.js inverts it. Your app starts once, holds its dependencies and state in memory, and answers every request from that same resident process. It consumes its memory footprint at 3 a.m. with zero visitors exactly as it does at peak.

What happens when a long-running process crashes

An unsupervised Node process that throws an unhandled exception doesn’t return a 500 and recover. It exits, the app stops answering, and every request after that fails until someone restarts it manually.

PHP has no equivalent failure mode. A fatal error kills one worker, the next visitor gets a fresh one, and nothing needs to be watching. That’s the problem a host solves before it can sell Node.js on a shared plan: something must monitor each application, restart it on exit, cap what it consumes, and stop one account’s memory leak from taking the neighbors down with it.

What changes on a host that does support Node.js

The host adds an application layer above the web server, and it does the supervision your app would otherwise need a VPS and PM2 to get. It’s the same division of labor that separates managed from unmanaged hosting: the supervision is the product, not something you configure.

That trade runs further than it first looks. The control panel covers the whole deployment, and the familiar hosting tools sit underneath it if you want them: a file manager, scheduled jobs, SSH access to your own account. What you do not get is a server to administer. Nobody is asking you to patch an operating system, configure a process manager, or decide how your app comes back after it falls over. Whether that reads as freedom or as a missing feature is the clearest signal of whether this kind of hosting is for you.

You set a handful of things in a control panel and the platform handles the rest:

• Runtime version. Which Node.js release the app runs on, selected per project rather than per server.
• Framework preset. The platform recognizes what you have built and fills in the build settings that suit it. You can override them, and the file that boots the app is worked out for you.
• Dependencies. The platform installs what your package.json declares, using the package manager you pick and produces the node_modules tree at deploy time.
• Connecting to the web server. You don’t configure this. The platform runs a web server in front of your app, connects the two, and maps your domain to it.
• Environment variables. Credentials and API keys live in the panel, not in your repository.

Where a shared plan can (and can’t) run a Node app

Two questions decide this, and most articles only ask the first. The first is whether your app is request-response or persistently connected. Request-response workloads fit shared plans well, and anything that holds an open connection to each client doesn’t, at any price tier, on any shared host.

The second gets asked far less often and matters just as much: how much does your app need you to operate it once it is live? A managed platform runs your code, not your server. If your app assumes it can reshape the server underneath it, or that something is watching the process on your behalf, that is the constraint worth weighing, more than the framework it happens to be written in.

Your app	Shared plan verdict
Express or Fastify REST API	Works
Next.js or Nuxt site with server-side rendering	Works
React, Vue, Svelte, or Astro front end with a build step	Works
NestJS or Koa backend service serving JSON	Works
App exported from an AI builder or vibe-coding tool	Works, if it’s a standard Node project with a package.json
Chat, live dashboard, collaborative editor, anything on Socket.io	Doesn’t work. Needs a platform that allows custom ports
Multiple client projects under one account	Works up to the plan’s project limit: 5 on GrowBig, 10 on GoGeek
App needing MySQL or PostgreSQL	Works. Both are available from Site Tools
App needing MongoDB or another non-relational database	Doesn’t work. You’d connect to an external managed service

Two verdicts you should reach without asking support. If your app answers HTTP requests and returns data or HTML, a shared plan carries it. If it pushes data to connected clients in real time, no shared plan will.

The second one catches people deploying something built with an AI tool. Most output from vibe coding workflows is a standard Express or Next.js project and deploys without incident. The exceptions reached for Socket.io because the prompt said “live”.

Ready to deploy rather than evaluate? This article covers whether a shared plan fits your app. For the step-by-step walkthrough, follow How to create a Node.js project in the knowledge base.

How SiteGround compares to Hostinger and app platforms

Two categories of providers answer this query, but they approach Node.js from different directions. Traditional web hosts add Node.js to a broader hosting account that can also run websites, databases, email, DNS, backups, and other services. App platforms put application deployment and runtime management at the center of the product.

The right choice depends both on what your application requires and what else you want the same hosting account to handle, which is an important part of choosing a web hosting partner.

Shared hosts: SiteGround, Hostinger, Namecheap

All three provide a managed interface for running Node.js applications, but their plan limits, deployment workflows, databases, and networking restrictions differ.

• SiteGround. Node.js is available from GrowBig upward, with up to 5 projects on GrowBig, 10 on GoGeek, and unlimited projects on Cloud. Apps can be deployed from GitHub with automatic redeployment or uploaded manually, with configurable build settings and deployment logs. MySQL and PostgreSQL are both available.
• Hostinger. Managed Node.js applications are available on Business Web Hosting and Cloud plans. It supports GitHub deployment, file uploads, configurable builds and managed MySQL. Incoming WebSocket connections aren’t supported on Web and Cloud hosting, so applications that require them need a VPS or another platform.
• Namecheap. Node.js is available on shared hosting through cPanel’s Setup Node.js App tool. PostgreSQL is also available on some shared plans, alongside MariaDB.

Database support is one practical difference. SiteGround provides PostgreSQL directly with its hosting, while Hostinger’s Web and Cloud plans provide MySQL and require an external service for PostgreSQL. That matters if your application is already built around Postgres and you want to keep the database inside the same hosting environment.

App platforms: DigitalOcean App Platform and Fly.io

App-focused platforms generally give you more flexibility around application runtimes, real-time connections, scaling, and deployment architecture. DigitalOcean App Platform supports WebSockets and horizontal scaling, while Fly.io lets you distribute and scale application Machines across regions.

The tradeoff isn’t simply managed versus unmanaged hosting. These platforms manage a substantial amount of infrastructure too. The difference is what they manage around your application.

A traditional hosting account is designed to bundle the other services a website commonly needs alongside the application. An app platform is designed primarily around deploying and operating the application itself, with databases, email, storage, domain registration, and other services added or connected according to the architecture you choose.

That makes the decision less about which category is universally more capable and more about what you want the hosting product to do. If Node.js is one part of a broader website setup, an integrated hosting account can reduce the number of systems you need to manage. If the application needs capabilities such as incoming WebSockets, more flexible scaling, or greater runtime control, an app-focused platform may fit the architecture better.

What you can’t do on any shared plan

WebSockets are not supported on any SiteGround plan. The documented alternative is long polling over standard HTTP and HTTPS, which is fine for a notification badge or a status check every few seconds, but not optimal for a chat app or a collaborative editor.

Three more limits apply across the whole shared hosting provider category:

• No custom inbound ports. Anything that expects to open its own listener for incoming connections won’t start.
• No root. You get SSH access to your own account and a file manager, so your project’s files are yours to read and change. What you can’t do is install system packages or alter how the server itself is configured.
• A fixed resource ceiling. A shared plan is a fixed slice of a shared machine, and an app that outgrows it wants a different tier rather than tuning.

If any of these is a hard requirement, upgrade the infrastructure instead of working around it. Reading the comparison of shared hosting against a VPS beats discovering the limit in production.

Node.js hosting on SiteGround

Plan tiers and project limits

StartUp does not support Node.js. Node.js availability starts on GrowBig and continues through GoGeek and Cloud.

Plan	Node.js projects	Web space
GrowBig	Up to 5	50 GB
GoGeek	Up to 10	100 GB
Cloud	Unlimited	40 GB to 1 TB

All extra services such as email, SSL, CDN and security features are included in all tiers, at no additional cost.

Deploying via GitHub or ZIP upload

There are two deployment paths, and the choice is worth making deliberately.

• Connect a GitHub repository. Every push to the linked branch rebuilds and redeploys automatically. This is the path for anything under active development.
• Upload an archive. The source goes up manually as a .zip, .tar.gz or .tgz file, with no auto-deploy. Every update is another upload.

Projects are created in Client Area > Websites > Node.js Projects, where you manage status, primary domain, and deletion. Deployment method, build settings, environment variables, and deployment logs live in Site Tools > Node.js.

Databases, domains, and what’s included

Every project launches on an auto-generated temporary domain, so the app is reachable and testable before any DNS points at it. You attach your own domain whenever you’re ready, which also lets a client review a staging URL without touching their live records.

MySQL and PostgreSQL are both created and managed from Site Tools. The plan also includes a free domain, email on that domain, SSL, the SiteGround CDN, daily backups, and WAF and DDoS protection.

A Node.js project isn’t a separate product here. It sits in the same account as your WordPress sites and static pages, sharing the same domain, email, and database tooling. If your app is a request-response API or a server-rendered front end, and you would rather not be responsible for the server underneath it, a shared plan is a real home for it.

The remaining choice is mostly about scale. GrowBig supports up to 5 Node.js projects, while GoGeek supports up to 10, with the rest of the hosting stack managed alongside them. If that integrated setup fits how you want to run your apps, compare the SiteGround Web Hosting plans and choose the tier that matches what you’re building.

[86]

Frequently asked questions

Once you buy hosting, your web hosting control panel is where you’ll run your site day to day, from setting up email and connecting your domain to restoring backups. Not every panel works the same way, though. Some are built for people who manage servers, and others are designed to keep everyday jobs simple. Here’s how control panels work, the main types, and what a good one looks like.

What is a web hosting control panel?

A web hosting control panel is a web-based dashboard for managing your hosting account and the websites on it. So instead of typing commands on a server, you use menus and buttons to handle domains, email accounts, files, databases, backups, and security settings from one place.

Think of it as the settings app for your hosting. For example, your phone runs thousands of processes you’ll never see, and the settings app gives you the handful of switches you actually need. A hosting control panel does the same for the server your site lives on.

Almost every type of web hosting comes with some kind of control panel, from entry-level shared plans to managed cloud servers. The basics look similar, but how much comes included varies from host to host and plan to plan:

• Everyday site jobs, such as email, domains, and one-click WordPress installs, are standard almost everywhere.
• Safety features, such as automatic backups and free SSL, vary a lot. Some hosts include them, and others sell them as add-ons.
• Developer tools, such as SSH access, PHP version control, and staging, are often reserved for higher-tier plans.

The main exception to all of this is an unmanaged server you set up yourself, which is a much more technical endeavor. There, you either install a panel or manage everything from the command line.

How a hosting control panel works

A hosting control panel sits between you and the software that runs your server. When you click a button, the panel translates that click into the commands the server needs, runs them, and shows you the result.

By way of example, here’s what happens when you create a new email address:

1. You fill in a short form in the panel with the address (hello@yourbusiness.com) and a password.
2. The panel tells the mail server to create the mailbox and sets up the settings it needs to send and receive messages.
3. The panel confirms the account is ready and shows you the login details for your email app.

Without a panel, the same job means connecting to the server with developer tools and editing configuration files by hand — and if you don’t know what that means, that’s exactly why you benefit from a control panel). 

The same pattern repeats for everything else in the panel. Restoring a backup, installing an SSL certificate, or adding a subdomain are all server tasks with a friendly form on top. If you’re still getting your head around how to host a website, the control panel is, thankfully, the piece that makes the whole setup manageable day to day.

What you can do in a hosting control panel

Nearly all the routine admin for your site happens in the control panel. Here’s what you’ll use it for, roughly in order of how often you’ll need it.

Manage your domains and DNS

Your control panel is where your domain and your site get connected. From there, you can:

• Point a domain at your website
• Add subdomains like shop.yourbusiness.com
• Edit DNS records, the instructions that tell the internet where your website and email live

If you’ve just registered a name, the next steps after buying a domain usually start here.

Create email accounts

The control panel is where you create email addresses on your own domain, such as hello@yourbusiness.com. You can also set up forwarders, so messages sent to that address land in an inbox you already check.

Install and manage websites

Getting a site into your hosting account starts in the control panel. You can set up WordPress or another app with an installer, or kick off a website migration if your site already lives with another host. Once it’s live, many panels also offer staging: a private copy of your site where you test changes before visitors see them.

Work with files and databases

The control panel gives you direct access to the behind-the-scenes parts of your site, the ones you never see while editing pages:

• File manager: browse, upload, and edit your site’s files in the browser
• FTP accounts: connect a desktop app like FileZilla to move files in bulk
• Database tools: view, export, or repair the data behind your site

If you manage your site through an app like WordPress, you’ll rarely need any of these. They’re there for the day something breaks and support asks you to rename a folder or check a file.

Back up and restore your site

Backups are your undo button, and the hosting provider control panel is where you find them. Look for automatic daily backups, a way to create your own copy before big changes, and a restore option that doesn’t require a support ticket.

Keep your site secure

The control panel holds the security settings that sit at the server level:

• SSL certificates: install and renew the SSL certificate that puts the padlock in the browser bar
• Blocked IP addresses: stop specific visitors or bots from reaching your site
• Password-protected folders: lock off parts of your site that shouldn’t be public

Server-side protection only goes so far, so pair it with a few basic website security tips like strong passwords and regular software updates.

Give other people access

If a developer, designer, or teammate works on your site, many hosts let you add them as a collaborator, either from the control panel or your hosting account. They get their own login with access to that site only, so you never share your password, and they can’t see your billing, invoices, or the rest of your account.

Your hosting account vs. control panel vs. WordPress admin

Your hosting account, your control panel, and your WordPress admin are three different areas with three different jobs. Beginners mix them up constantly, which is why “how do I log in?” shows up in search so often.

Here’s what each area handles:

	Hosting account	Control panel	WordPress admin
What it’s for	Billing, plans, and account details	Running the hosting behind your site	Building and editing the site itself
Typical tasks	Pay invoices, upgrade your plan, contact support	Create email, restore backups, manage DNS	Write posts, install plugins, change your theme
Example	Renewing your plan before it expires	Setting up hello@yourbusiness.com	Publishing a new blog post

A quick rule of thumb:

• If the task is about money or your plan, it’s the hosting account.
• If it’s about what visitors see on your pages, it’s WordPress.
• Everything in between lives in the control panel.

Some WordPress hosting plans blur the lines by adding WordPress tools to the panel, such as automatic updates or staging. The three areas still do separate jobs. At SiteGround, for example, the Client Area is your hosting account and Site Tools is your control panel. Your WordPress admin is the dashboard you reach by adding /wp-admin to the end of your site’s address, and it’s where you edit your pages and posts.

The main types of web hosting control panels

Back to the control panel itself. Not every host gives you the same one, and the panel you end up with depends on who hosts your site and how much of the server you manage. Almost every panel falls into one of these categories.

1. Third-party panels

A third-party panel is a ready-made control panel that a host licenses from a software company instead of building its own. It looks and works the same no matter which host you’re with, with the same menus for email, domains, files, and backups. cPanel and Plesk are the best-known examples, and you’ll find them on many shared and reseller hosting plans.

That consistency cuts both ways. What you learn in one account carries over to the next, but if a menu confuses you or a routine task takes too many clicks, it’ll be the same at every host that uses that panel. The host can’t redesign it either, because the software company decides what changes and when.

2. Free and open-source panels

Free, open-source panels such as CyberPanel and aaPanel are ones you install yourself, usually on a VPS or dedicated server. They cost nothing to license, but you’re responsible for setup, updates, and security. They suit developers who are comfortable with unmanaged hosting better than someone launching a first site.

3. Panels built by the hosting company

Some hosts build their own panel for their own platform. Because the host owns the design, it can shape the panel around what its customers actually do, such as keeping backups and SSL a click away, and fix what users find frustrating without waiting on an outside vendor. The tools are also built for the exact servers the host runs, so features like caching and WordPress management fit the platform instead of being generic.

SiteGround’s Site Tools is one example. SiteGround built it for its own hosting platform and organized it around individual websites instead of the hosting account, so each site gets its own panel with its own settings. If you manage more than one site, you can switch between them from a dropdown in the header, including sites in different SiteGround hosting accounts.

In Site Tools, you’ll find:

• More than 35 tools in one panel, from email and domains to caching, CDN, and site statistics
• One-click WordPress installs, automatic updates, and migrations from other hosts, with staging on the GrowBig plan and higher
• 30 days of automatic daily backups on shared hosting plans, with free restores
• A free Let’s Encrypt SSL certificate for new sites that renews automatically

If you’d like to see how it’s laid out, the free Site Tools demo lets you try it before signing up.

What to look for in a control panel

Your control panel usually comes with your hosting plan, so judging a panel is part of choosing a web hosting partner. It’s also a quick health check if you already have hosting and something feels harder than it should. A good panel passes these checks:

• You can find things. Common jobs like creating an email account or restoring a backup take a few clicks, and a search bar covers the rest.
• Help is a click away. You can reach support from inside the panel, and tools link to guides that explain what they do, so you’re not stuck searching forums when something breaks.
• Backups run on their own. Daily backups happen without you, and restoring one doesn’t need a ticket or a fee.
• Security basics are included. Free SSL with automatic renewal comes with the plan, and anything paid is clearly labeled as paid.
• It’s fast. Pages in the panel load quickly, even when you’re managing several sites.
• It works on your phone. You can check a backup or fix a DNS record from a mobile browser when you’re away from your desk.
• It grows with you. Adding a second site, or a tenth, doesn’t turn the panel into a maze.

If your current panel fails two or three of these, that’s a fair question to raise before your plan renews. A panel you dread opening is a panel you’ll avoid, and avoided panels are where expired SSL certificates and missing backups tend to hide.

A good control panel makes the rest of hosting feel easier

A web hosting control panel is where the practical side of running a site happens: email, domains, backups, security, and the occasional emergency restore. It can look intimidating at first, but a well-designed panel keeps those jobs simple enough to handle on your own.

When you’re comparing hosts, take a close look at the panel you’ll be working in every day. SiteGround Web Hosting comes with Site Tools, so daily backups, free SSL, and one-click WordPress installs are ready from your first login.

[86]

Frequently asked questions about website hosting control panels

Almost every hosting provider describes its hosting as secure. Far fewer readers can say what that actually means, and that gap is the real problem. Most compromises don’t start where people expect them to, and the fix usually isn’t on the server at all.

Web hosting security is the combined set of protections across two layers: the server layer, where your host handles patching, service configuration, network filtering, and account isolation, and the account layer, where you handle credentials, user roles, software versions, and backups. Server security covers the first layer only.

Why your hosting can look secure and not be

The reason hosting can look secure without being secure is that most of the visible signals measure activity, not outcomes. A host publishing a security page is doing marketing. A plugin sitting in your admin is doing detection. Neither tells you whether the specific door an attacker would use is locked.

This matters because security work is invisible when it succeeds. Patching, isolation, and monitoring produce no user-facing evidence at all, so the reader is left inferring protection from proxies. Those proxies are weak, and they’re weak in a predictable direction: they all overstate coverage.

The usual website security tips are sound as far as they go, but they don’t tell you which of the two layers your gap sits on. That’s the question that decides whether the next hour of your time should go to your host’s support team or to your own admin panel, and almost no discussion of website hosting security answers it before handing you a checklist.

The three signals people mistake for evidence

These three signals show up in almost every conversation about hosting security, and none of them is evidence of protection. Each one is true and each one is answering a different question than the one you asked.

1. The padlock in the address bar

An SSL certificate encrypts traffic between the visitor’s browser and your server. That’s it. It says nothing about who can log in to your admin panel, whether your plugins are current, or whether the server was patched this month. A phishing site with a valid certificate gets the same padlock as any other website working through HTTPS.

2. Nothing has happened yet

An uneventful year is the weakest signal of the three, because most automated attacks are indiscriminate and most successful ones stay quiet. A site can host a backdoor for months while serving normal traffic. Absence of a visible incident measures your luck and your monitoring, in unknown proportions.

3. A security plugin is installed

Installing a plugin is not the same as configuring one, and a plugin’s reach stops at the application. Solid WordPress security work happens here, but it happens on your layer, above the operating system and the web server. A plugin can’t patch the software it runs on.

The two layers of hosting security, and which one is yours

Every control in hosting security sits on one of two layers, and each layer has exactly one owner. Get the boundary wrong and you either try to harden things you don’t control or ignore the things you do.

What sits on the server layer (your host’s job)

The server layer is everything below your account, such as: 

• physical hardware, 
• the network edge, 
• the operating system, 
• the services running on it. 

Your host owns operating system patching, web server and database configuration, network filtering and brute-force protection at the edge, account isolation between neighbors on the same machine, and intrusion detection and log monitoring. 

You don’t have root access on shared, managed, or most cloud plans, so you can’t do this work even if you want to.

What sits on your account and website layer

Your layer is everything you can reach after logging in: hosting account and admin passwords, two-factor authentication, user roles and permissions, application and plugin versions, API keys and tokens, old test installs and staging copies you forgot about, FTP and SSH credentials, and your backups. 

Control	Server layer (host)	Account layer (you)
Operating system and service patching	Yes	No
Web server, database, and PHP-FPM configuration	Yes	No
Network firewall and brute-force filtering	Yes	No
Account isolation between neighbors	Yes	No
Intrusion detection and log monitoring	Yes	No
Passwords and two-factor authentication	No	Yes
User roles and permissions	No	Yes
Plugin, theme, and core versions	No	Yes
API keys, FTP users, and SSH keys	No	Yes
Backup coverage and restore testing	Shared	Yes

Where server-layer security usually fails

Server-layer failures are rarely exotic. They cluster in three places: software left unpatched past a published vulnerability, services exposed to the network that didn’t need to be, and configuration that was never tightened from its installation defaults. The third is the most common, and it’s the one with a name.

On shared hosting the additional failure mode is isolation. Multiple accounts run on one machine, so the question that matters is whether a compromise inside one account can read or write anything in another. That boundary is the host’s to build and the host’s to prove.

What a server security misconfiguration actually looks like

A server security misconfiguration is a setting that was left at a permissive default rather than being deliberately set. Two examples cover most of what goes wrong.

The first is a file-permission default. Directories on a correctly configured account sit at 755 and files at 644, which lets the web server read them and stops other processes writing to them. A directory left at 777 is writable by any process on the machine, so an attacker who gains a foothold anywhere gets a place to drop a file that then executes as your site.

The second is an exposed admin panel. Database managers, monitoring dashboards, and server control panels frequently install with a default port, a default path, and sometimes a default credential pair. Nothing is broken, and nothing is patched incorrectly. The panel is simply answering requests from the entire internet when it should answer requests from one IP address. OWASP tracks this whole category as security misconfiguration in its Top 10.

Where your own layer usually fails

Account-layer failures are boring, repetitive, and responsible for most of the incidents that actually happen. These four are most common:

• A reused admin password. The password on your WordPress admin or hosting account also exists in a breach dump from an unrelated service. No exploit is required, because credential-stuffing tools simply try it. This is the single most common way small sites are taken over.
• Un-updated plugins and themes on a set-and-forget site. A site built two years ago and left alone runs code with publicly documented vulnerabilities and published proof-of-concept exploits. The gap between disclosure and mass automated scanning is measured in days, not months.
• An old developer’s FTP or SSH credentials, never revoked. The freelancer who built the site in 2023 still has access, and so does anyone who has since compromised their laptop. Here’s the part that catches people out: deleting an FTP account in Site Tools does not revoke an SSH key. Keys are managed separately under Site Tools > Devs > SSH Keys Manager, and they can outlive the FTP user created alongside them. 
• A backup that’s never been test-restored. Backups run nightly and nobody checks them, so the first restore attempt happens during an incident, under time pressure, with no fallback. Untested backups fail in mundane ways: a database export that excluded a table, a job that broke six weeks ago, retention shorter than the time it took to notice the problem.

Two of those four are access problems, which is why the principle of least privilege does more for a small site than any plugin: every account, key, and role that exists is a way in, so the ones nobody needs should stop existing.

What good hosting security looks like, and what SiteGround does

Real server-layer security is describable. A host should be able to name its patching cadence, its isolation method, the type of firewall at the edge, what it monitors, and what it does when something is found. Here is our side of the line, in those terms.

• Account isolation on shared servers, so a compromise in one account can’t reach the files or database of another.
• A web application firewall with rules written and deployed by our own security team, including virtual patches for newly disclosed WordPress and plugin vulnerabilities, often before the vendor’s own fix is available.
• AI-driven anti-bot protection at the network edge, which blocks brute-force login attempts before they reach your site.
• Managed operating system and service patching, applied across the fleet rather than left to individual accounts.
• Daily automated backups, restorable from Site Tools > Security > Backups, with files and databases restorable separately so you can roll back a database without losing files uploaded since. 
• Site Scanner, which checks for malware daily and alerts you rather than waiting for a visitor to find it.

None of that is a substitute for the work on your layer, and any host claiming otherwise is describing half a system. What it does mean is that the questions in the next section have concrete answers here.

What you should have in place on your side

Your layer comes down to eight items. Each one closes a door that automated attacks actually use.

• Two-factor authentication on your hosting account and your site admin, enabled from the Client Area under Login & Profile.
• A unique password on every account, generated rather than chosen, and never reused across services.
• Core, plugin, and theme updates applied on a schedule you can name, with automatic updates on for anything you don’t review manually.
• Admin accounts audited quarterly, with unused users, contributors, and old developer logins deleted rather than deactivated.
• FTP users and SSH keys reviewed at the same time, and revoked separately, since removing one does not remove the other.
• A restore you have actually performed, on staging, within the last six months.
• Malware scanning running on a schedule, with alerts going to an address someone reads.

The longer list of website security tactics extends this, but these eight are the ones with the worst consequences when they’re missing. If you do nothing else after reading this, run a malware scan and open your list of admin users. Both take under five minutes and are the surest way to prevent bigger issues in the future.

Six questions to ask, and what a real answer sounds like

Ask before you buy, and ask again if you’re already hosted somewhere. Two patterns tell you most of what you need. A real answer names a mechanism, a frequency, or a boundary. A weak answer restates the question as a value.

Choosing a web hosting partner on this basis is more predictive than any feature grid. The six questions below are ordered by how much a wrong answer costs you, so if you only get through the first two before the chat window closes, you’ve asked the two that matter most.

Each question below targets one server-layer control. The answers you want are boring and specific.

1. How quickly do you patch a disclosed vulnerability?

A real answer names a timeframe and distinguishes severity levels: critical patches within hours, routine updates on a weekly cycle. It may also mention virtual patching at the firewall for cases where no vendor fix exists yet. A weak answer says the provider keeps everything up to date.

2. How are accounts isolated from each other on a shared server?

A real answer names the mechanism, whether that’s containerization, per-account users with enforced permission boundaries, or dedicated resource allocation, and states plainly that one account can’t read another’s files. A weak answer says accounts are separate, which is a restatement of the question.

3. What kind of firewall do you run, and who writes the rules?

A real answer distinguishes a network firewall from a web application firewall, says who authors the rules, and says how often they’re updated. In-house rules updated continuously are stronger than a vendor rule set applied at defaults. A weak answer says the provider has enterprise-grade firewalls.

4. What do you monitor, and what happens when you find something?

A real answer describes both detection and response: what’s watched, what triggers an alert, whether a human reviews it, and whether you’re contacted or the account is suspended first. Recognized references such as NIST SP 800-123 treat logging and monitoring as a baseline server-security control, not an add-on. A weak answer mentions 24/7 monitoring with no object.

5. How often do you back up, and have you tested a restore?

A real answer gives a frequency, a retention period, where copies are stored, and who can trigger a restore. Ask specifically whether you can restore without opening a ticket. If you’re running a store or anything transactional, daily backups may not be frequent enough for your data loss tolerance, and that’s worth establishing before you need it.

6. Which parts of security are mine on this plan?

A real answer draws the line clearly and doesn’t claim the whole stack. A host that says it handles all of your security is either wrong or describing a managed service far above the price you’re paying. The best answer is the honest one, because it tells you exactly what’s left on your desk.

Where the line moves: shared, managed, VPS, and dedicated

The boundary between the two layers isn’t fixed. It moves with hosting type, and this is the single most common source of confusion when people read security checklists written for someone else’s setup.

Hosting type	Server layer owner	What you own
Shared hosting	Host, entirely	Account and website layer only
Managed WordPress hosting	Host, plus application-level patching	Credentials, roles, content, and often plugin choices
Managed VPS	Host for the base stack, you for what you install	Everything above the managed baseline
Unmanaged VPS or dedicated	You	Operating system, services, firewall, patching, and the account layer

The practical consequence is that the same checklist item can be someone else’s job or yours depending on the plan you’re on. “Configure your firewall” is impossible advice on shared hosting and mandatory advice on an unmanaged VPS, yet most best-practice lists print it without saying which reader it’s for. That’s the single biggest reason security checklists feel simultaneously overwhelming and useless.

This is why the distinction between managed and unmanaged hosting is a security decision and not only a convenience one. An unmanaged server gives you root access and the full responsibility that comes with it, which is a good trade only if someone is going to do the work. If nobody on your side is going to patch an operating system on a Tuesday, moving up the stack for control moves you down in actual security.

When something gets through anyway

No configuration on either layer reduces risk to zero, and any provider implying otherwise is selling. Attacks succeed against patched servers and audited accounts, usually through a vulnerability disclosed and exploited on the same day, or through a credential that was valid and stolen.

What separates a bad afternoon from a bad quarter is preparation, and it comes down to three things you can settle now: 

• a backup you’ve restored before, so recovery is a procedure rather than an experiment; 
• a written record of who has access to what, so you can revoke quickly instead of guessing; 
• knowing who to contact and what they’ll need from you 

Knowing the recovery steps for a hacked site in advance also removes the worst decisions from the worst moment, because the order of operations matters. Clean before restoring and you may reinfect from a compromised backup. Restore before finding the entry point and you’ll be doing it again next week.

Assumed or verified security: the difference that matters

Assumed security and verified security look identical right up until they don’t. The difference is that verified security has answers attached: a patching cadence you were told, an isolation mechanism you can name, a restore you performed yourself, and a list of accounts you’ve actually read. Web hosting security stops being a feeling at the point where every claim on both layers has something concrete behind it.

If you take one thing from this, take the boundary. Work out which layer your gap is on, then do the work that’s yours and ask the questions that aren’t. If the answers from your current provider come back vague, SiteGround web hosting plans are built so that every item in the six questions above has a specific answer.

[86]

---

Frequently asked questions

You pushed an update an hour ago. You can see the new version. Some of your visitors can’t. That’s your CDN cache doing exactly what you told it to: serving a saved copy instead of asking your server for a fresh one. It’s rarely a real bug, and it’s usually fixable in a few minutes once you know which copy is stale and how to clear it.

What is a CDN cache, and why it’s not the villain here

A CDN cache is a set of temporary copies of your site stored on a network of edge servers around the world, so visitors download your pages from a server near them instead of from your origin every time. It exists to make your site faster and to take load off your origin server, and for static content it does that job well. When it “misbehaves,” it’s almost always following the rules you (or your platform) gave it.

That framing matters, because the fix is rarely “turn off the CDN.” The fix is usually “tell the cache the content changed.” If you want the full definition of the delivery layer itself, SiteGround’s explainer on what a content delivery network is covers the network side in detail. Here, the important part is narrower: the cache is a copy, copies go out of date, and out-of-date copies are the entire problem you’re troubleshooting.

So when your CDN keeps showing an old version, it hasn’t failed. It’s holding a copy that was correct when it was stored and is now behind your latest change.

Cache HIT, MISS, and TTL: how long your CDN actually holds a page

Every request to your CDN ends in one of two outcomes:

Outcome	What the edge server does
Cache HIT	It already has a copy and serves it instantly.
Cache MISS	It has no copy, so it fetches from your origin, serves that, and stores a copy for next time.

A high ratio of HITs is what keeps your time to first byte low and your origin quiet.

How long the edge keeps that copy is the TTL, set by response headers like Cache-Control: max-age (for browsers) and s-maxage (for shared caches such as a CDN). A max-age=3600 says “this is good for 3,600 seconds,” so the edge will keep serving it for an hour before checking back.

This is the direct answer to “how long does it take for a CDN to cache a page” and “how long until my change shows up.” The cache stores a page on the first request after a MISS, and it holds that copy until the TTL expires or you purge it. Many CDNs default to a TTL of several hours.

CDN vs. cache vs. browser cache: which one is actually serving you old content?

Before you purge anything, figure out which layer is stale, because purging the wrong one wastes time. A cache is just a stored copy of data, and on a typical site there are at least three of them stacked between your server and your visitor’s screen:

Layer	Where it lives	Can you purge it?
Origin/server cache	On your host (page cache, object cache)	Yes, from your hosting tools. A CDN purge won’t touch it.
CDN cache	On the edge network worldwide	Yes, with a CDN purge. This is the layer serving most visitors.
Browser cache	On each visitor’s own device	Not remotely. You influence it with headers and cache-busting.

Then run a quick diagnostic:

• Only you see the old version? Probably your browser. Hard-refresh or test from incognito to confirm.
• Everyone sees it, including you in a private window? It’s the CDN or origin.

A CDN is not the same thing as a cache. It’s a delivery network that happens to use caching as its main mechanism, which is why “is a CDN a cache” gets a “sort of, but not only.”

Why your CDN broke your site: 6 causes (and the one everyone misses)

Almost every stale-or-broken-after-deploy case traces back to one of these causes. Getting this wrong doesn’t just annoy visitors. Broken assets hurt conversions and the site speed signals search engines watch.

1. Stale asset after a deploy. You changed a file but its URL stayed the same, so the edge keeps serving the copy it has until the TTL runs out.
2. TTL set too long. A generous max-age is great for images that never change and painful for files you edit weekly. One TTL rarely fits every asset type.
3. Dynamic pages got cached. Cart, checkout, account, and logged-in views should never be cached at the edge. When they are, visitors see each other’s stale state, which is where “cdn cache not updating” turns into an actual bug.
4. No cache-busting on updated files. If style.css is always style.css, caches can’t tell v1 from v2, and the old copy wins.
5. Misconfigured Cache-Control headers. A missing no-store on a private page, or an s-maxage that contradicts your intent, quietly tells the CDN to do the wrong thing.

The one everyone misses: asset-version mismatch

This is the true breakage case, and the sixth cause on the list. Cached old HTML references files that changed, or fresh HTML loads a cached old stylesheet or script. The result is a page that renders broken, not merely out of date: unstyled layouts, missing images, JavaScript errors. It looks like your site collapsed. It’s really two cache layers that fell out of sync.

How to clear your CDN cache right now (and what WordPress plugins actually clear)

The fastest fix for “how to clear CDN cache” is a manual purge, and it forces the edge to fetch fresh copies from your origin on the next request. Here’s the general path, then what actually changes for WordPress.

1. Open your CDN or hosting dashboard.
2. Find the caching section for your site.
3. Look for a purge or flush/clear cache button and click it.
4. Reload the affected page in a private window to confirm the new version.

On SiteGround, you flush the CDN cache from Site Tools under Speed > CDN, where the Cache Purge button clears every cached resource (it can take up to 60 seconds to propagate globally).

“How to clear CDN cache in WordPress” trips people up, because a WordPress plugin usually isn’t what clears the CDN edge. On SiteGround you still purge the CDN from Site Tools > Speed > CDN, exactly as above. The Speed Optimizer plugin, which also manages browser caching in WordPress, has a Purge SG Cache button, but that clears the server-side Dynamic Cache, a different layer. So if visitors still see the old version after a plugin purge, the CDN edge is what still needs clearing.

The faster fix: preview changes live without a full purge

Purging works, but it’s a blunt instrument. Every full purge sends all your traffic back to the origin at once, which is the opposite of what a CDN is for. The better move while you’re still editing is to preview changes without clearing the cache for everyone.

SiteGround CDN includes a development mode that temporarily suspends caching for 30 minutes, then toggles itself back off automatically. While it’s on, requests skip the cache so you see your changes immediately. The advantage over a full purge is that your cached copies are never wiped, so the moment development mode ends your hit ratio is right back where it was instead of rebuilding from zero. It’s a single toggle in Site Tools, which makes it one of the more practical additions to a WordPress performance workflow rather than a feature you’ll read about and never touch.

Use the preview to confirm the change looks right, then purge once, deliberately, instead of purging repeatedly while you guess.

How to cache safely so this doesn’t happen again

Safe caching isn’t about caching less. It’s about caching the right things for the right length of time. The habits below prevent almost every case above, and they keep the speed benefits that improve your Core Web Vitals.

Do	Don’t
Cache static assets (images, fonts, compiled CSS/JS) with long TTLs	Cache HTML for logged-in, cart, or checkout pages
Version filenames (app.9f2c.js) so a change is a new URL	Reuse the same filename across releases
Set Cache-Control: no-store on private or personalized pages	Rely on a single TTL for every asset type
Purge automatically on every deploy	Purge manually and hope you remembered

The single highest-value habit is cache-busting through versioned filenames. When a changed file gets a new URL, every cache treats it as new content automatically, and the asset-version mismatch that breaks pages simply can’t happen. Caching compiled CSS and JavaScript at the edge also helps you eliminate render-blocking resources, since returning visitors load them instantly instead of downloading them again. Pair that with purge-on-deploy and most stale-content tickets disappear before anyone files them.

Cache invalidation vs. purging: why flushing everything is overkill

CDN cache invalidation means telling the cache that specific content is no longer valid, so the edge refetches only what actually changed. A full purge wipes everything. Invalidation surgically removes the three files you touched. The difference shows up immediately in your website performance metrics: a full flush drops your cache hit ratio to 0% and hammers your origin until the cache refills, while targeted invalidation barely moves it.

For a small brochure site, flushing everything is fine. For a busy store or a high-traffic blog, it’s the difference between a smooth deploy and a few minutes of slow, origin-bound page loads for every visitor. The rule of thumb: invalidate by URL or tag when you can, and reserve the full purge for the rare case where you genuinely don’t know what changed.

This is also where your host earns its keep. A platform that invalidates intelligently on publish protects your hit ratio for you, so you get fresh content without the performance dip.

[86]

Put your caching on autopilot

Most of the trouble in this article comes from doing CDN cache management by hand: remembering to purge, guessing which layer is stale, and hoping a full flush doesn’t slow everyone down. A managed platform removes those decisions. SiteGround CDN caches your static content on a global edge network, clears on demand with a one-click purge from Site Tools, and includes a development mode for previewing changes without wiping your cache.

That means you can ship changes without babysitting the cache, and your visitors keep getting the fast, current version of your site. Fast by default, current when it matters, and no 2 a.m. “why is the old homepage still up” panic.

Frequently asked questions

Your email didn’t break. When you changed your domain’s nameservers, mail routing moved to a new DNS provider that doesn’t have your old records, so messages have nowhere to land. Email not working after a DNS change is almost always a case of missing MX and supporting records, not lost data. Recreate the right records at your new DNS host, wait for propagation, and mail comes back.

Why email stops working after a DNS change

Nameservers decide which company answers questions about your domain, and DNS records are the individual answers. When you point your domain to a new host, you switch to a fresh DNS zone that starts with a default set of records. That default set rarely includes the exact MX, SPF, and mail records your email provider needs, so incoming mail has no address to route to.

This is why the question “does changing nameservers affect email” comes up so often: the change itself is harmless, but the empty zone behind it is not. If you recently pointed your domain to a new host, the previous provider’s records stayed behind on the old nameservers. Nothing was deleted. The new nameservers simply never received a copy.

The reassuring part: your account, passwords, and stored messages sit on the mail server, which the DNS change never touches. You are reconnecting the signposts, not rebuilding the mailbox.

First, confirm the problem is actually DNS

Before editing anything, rule out the faster explanations. A wrong password, a provider outage, or a change made only minutes ago can all look identical to a DNS problem, and none of them are fixed by touching records.

Run three quick checks:

1. Timing. If you changed nameservers in the last hour, the issue may just be propagation. Note the exact time you made the switch.
2. Login and outage. Try webmail directly. If you can log in and see old messages but no new ones, DNS is the likely culprit. If you cannot log in at all, check if your provider is experiencing server issues.
3. Both directions. Test sending and receiving separately. Which one fails tells you which records to check, and it saves you from editing records that were never the problem.

If webmail loads your history but new mail stopped arriving right after the switch, you are looking at a records issue. Move on to the diagnosis.

Find out which records went missing

Email relies on several record types working together, and a DNS change can drop any of them. Rather than guessing, look up what is currently live on your domain. A free tool like MxToolbox returns your MX records in seconds, and most DNS hosts show the full zone inside their control panel. Compare what you see against what your email provider says you should have.

Here is what each record does and how its absence shows up:

Record	What it does for email	Symptom if missing or wrong
MX	Points incoming mail to your mail server	You stop receiving email entirely
A / CNAME (mail, webmail, autodiscover)	Lets clients reach the server and auto-configure	Outlook or Apple Mail cannot connect or set up
SPF (TXT)	Lists servers allowed to send as your domain	Your outgoing mail lands in spam or is rejected
DKIM (TXT)	Signs messages so receivers trust them	Reduced deliverability, spoofing warnings
DMARC (TXT)	Tells receivers how to handle failed checks	Inconsistent delivery, no reporting

In SiteGround, the full zone is listed under Site Tools > Domain > DNS Zone Editor, in the Manage DNS Records table.

Here you can see exactly what is live on your domain after pointing it to SiteGround’s nameservers. The three MX records, the mail-related A records (autodiscover, autoconfig, mail), and the DKIM CNAME are all present. Compare your own list against what your email provider expects.

[86]

Check your MX records first

MX records are the first thing to verify, because without them nothing arrives. A correct set points to your provider’s mail hostnames, each with a priority number where the lowest value is tried first. Google Workspace, for example, publishes:

smtp.google.com at priority 1 (the current single-record setup), or the classic five-record set led by ASPMX.L.GOOGLE.COM at priority 1, with four ALT records at priorities 5 to 10.

Your provider’s set may differ, so use its exact hostnames and priorities. They should be available in your old DNS zone, or in their official product documentation.

If your lookup still returns SiteGround’s default MX, or any host that is not your email provider, that mismatch is your receiving problem in one line.

Check the A and CNAME records for mail access

Whether you need these at all depends on the provider:

• Traditional, host-based email (including old cPanel-style hosts) usually uses hostnames such as mail.yourdomain.com and autodiscover.yourdomain.com so desktop clients can connect and auto-configure.
• Google Workspace needs none of these, because Gmail is the interface.
• Microsoft 365 wants an autodiscover CNAME pointing to autodiscover.outlook.com.

Check your provider’s documentation for the exact hostnames, and if it lists none, leave these out. When they are required but missing, mail can route fine while Outlook or Apple Mail sits there failing to connect.

Check SPF, DKIM, and DMARC for sending

These three TXT records decide whether the rest of the internet trusts mail sent from your domain. They do not affect receiving, but a missing or wrong SPF record after a DNS change is the usual reason your sent mail suddenly lands in spam. Each value is provider-specific. Using Google Workspace as an example again:

• SPF is v=spf1 include:_spf.google.com ~all.
• DKIM is a google._domainkey TXT record holding the key you generate in the Google Admin console.
• DMARC is a _dmarc TXT record such as v=DMARC1; p=none; rua=mailto:you@yourdomain.com. 

Copy your provider’s exact strings, since a single wrong character in any of them breaks the check.

Restore the records at your new DNS host

Once you know which records are needed, recreate them in your new DNS zone using the values from your email provider. In SiteGround, you edit these under Site Tools > Domain > DNS Zone Editor, where a tab at the top of Create New Record lets you pick each record type — A, AAAA, CNAME, MX, SRV, or TXT — and fill in its fields.

To restore receiving, open the MX tab, choose Add your own MX records, then enter the mail hostname your provider lists in Destination and its Priority. The same panel handles A, CNAME, and TXT records via the other tabs.

Work in this order:

1. Add the MX record with the exact mail hostname and priority your provider lists. This restores receiving.
2. Add the mail A or CNAME records (mail, webmail, autodiscover) so email clients reconnect.
3. Add the SPF, DKIM, and DMARC TXT records exactly as published, character for character.
4. Save and re-run your MX lookup to confirm the new records are visible.

Receiving vs sending: different symptoms, different fixes

Treat “I can’t receive” and “I can’t send” as two separate problems, because they live in different records. Fixing one does nothing for the other, and editing the wrong set just adds risk.

• If mail is not arriving, the fault is in MX or the mail A records. 
• If mail sends but bounces or lands in spam, the fault is in SPF, DKIM, or DMARC. 

That second case is really a deliverability problem, and the same authentication records that fix it also protect your email deliverability. Diagnosing the direction first turns a vague “email is down” into a specific record to repair.

How long until email works again

After you save correct records, email usually starts flowing within a few hours, but full propagation can take up to 24 to 48 hours. 

Resist the urge to keep editing DNS while you wait. Every change resets the clock and makes the delay worse, not better. Save the correct values once, verify them with a lookup tool, and give propagation time to finish. If mail still fails after 48 hours, the problem is the record values themselves, not propagation, so recheck them against your provider.

How to change nameservers without affecting email 

The clean way to change nameservers without affecting email is to prepare the new zone before you flip the switch, not after. A little sequencing removes the downtime entirely, and it is the same discipline behind any careful website migration.

Use this checklist before your next change:

1. Record your current zone. Export or screenshot every existing record, especially MX, SPF, DKIM, and any mail hostnames.
2. Recreate the records at the new host first, while the domain still uses the old nameservers.
3. Switch the nameservers, then verify sending and receiving with a real test message.

Done in this order, mail keeps flowing through the switch because the new zone already knows where to send it.

When to call in help

If you have restored the records, waited out propagation, and mail still fails, it is time to involve people who can see the server side. Your email provider can confirm the exact record values, and your hosting support can verify the zone is applied correctly. 

This is also where the choice of provider matters. When email, DNS, and hosting sit with one company that offers real human support, a broken record is a five-minute chat rather than a multi-day back and forth across three providers. This is worth weighing when choosing a web hosting partner, because the cheapest plan often means you are the support team.

The bottom line

Email breaking after a DNS change is a routing problem, not data loss. A nameserver switch hands your domain to a new DNS zone, and until that zone’s MX and mail records point back at whoever hosts your mailboxes, incoming mail has nowhere to go. 

The fix is methodical rather than urgent: confirm the problem is DNS, pull the correct values from your provider or your old zone, replace the defaults, and let propagation finish before you judge the result.

The durable lesson is sequencing. Treat DNS records as part of any nameserver move, not an afterthought: stage the records at the new host before you flip, and test both sending and receiving before you call it done. Handle it that way and “email not working after a DNS change” stops being an emergency and becomes a checklist.

Frequently asked questions