Author: Aleksandar Kolev

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

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.

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.

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

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.

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.

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

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. 

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.

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:

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:

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.

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:

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

Multiple cache layers usually coexist without issues. The real problem starts when two or more systems try to control full-page (HTML) caching independently, which causes stale content, wrong data for logged-in users, and purges that seem to do nothing.

When caching starts working against you

You publish a content update, but visitors still see the old version. A logged-in customer sees someone else’s cart data. The site loads fast on one request and slow on the next, with nothing changed on your end. You clear the cache, and nothing happens.

That last symptom is the tell. A single, well-behaved cache clears when you tell it to. When purging changes nothing, more than one system is caching the same HTML page, each with its own rules for when to store, serve, and expire it. They don’t know about each other, so clearing one leaves the others serving their own copies.

It happens more often than you’d expect:

• A WordPress site running two caching plugins, each generating its own static HTML.
• A CDN caching HTML responses while a plugin also generates static pages.
• A host’s server-level cache overlapping with a plugin’s page cache.

The fix isn’t to disable caching. It’s to find where page caching is duplicated, remove the overlap, and let one system own the HTML.

What a website cache does

A website cache stores a copy of your site’s content so it can be served faster on repeat requests. Instead of rebuilding a page from scratch on every visit, the web server (or browser, or CDN) delivers a saved version. That reduces load time, lowers server resource usage, and improves the experience for visitors.

There are several distinct layers, each operating at a different point in the delivery chain.

In most setups, these layers handle different content types or serve different purposes and work fine together. The conflict zone is specifically full-page HTML caching, where server cache, application cache, and sometimes CDN cache overlap.

Where conflicts actually happen

Browser cache and CDN cache for static assets (images, CSS, JS) rarely cause problems. These layers store different file types, operate at different points in the chain, and don’t interfere with each other. The real issues come from duplicate page caching: two or more systems that independently generate, store, and serve cached HTML.

Common misconfigurations

Why duplicate page caching is hard to debug

In a well-configured caching system, troubleshooting is simple: clear the cache, test the page, check the result. With two or more systems caching HTML independently, that process breaks down.

You purge the plugin cache, but the server cache still serves an old version. Then you clear the server cache, but the CDN holds its own copy. You purge the CDN, but the browser cache on the visitor’s device still shows stale content. Simple fixes turn into a cycle of clearing everything, testing blindly, and hoping the site works for everyone.

How to check which layer served a page

You can debug this from your browser, and it’s easier than you think. You can identify which caching system served a page by inspecting the HTTP response headers in your browser’s DevTools.

Open the Network tab, reload the page, click the HTML document request, and check the response headers.

Headers to look for:

• x-cache or x-proxy-cache: shows whether the server or reverse proxy served a cached version (typically HIT or MISS).
• cf-cache-status: a Cloudflare-specific header. Values like HIT, MISS, DYNAMIC, or BYPASS tell you whether Cloudflare served the page from its cache.
• age: the number of seconds the response has been stored in cache. A high value right after publishing a change means a layer is serving stale content.
• cache-control: the caching rules the server sent to the browser and intermediaries. Look for max-age, no-cache, or private directives.

Here’s an example of response headers showing the page was cached at the server level:

x-proxy-cache: HIT
cache-control: public, max-age=86400
age: 532

If you see cache HIT headers from two different systems on the same HTML response, or if purging doesn’t change the age value, you likely have overlapping page caches:

x-proxy-cache: HIT
cf-cache-status: HIT
age: 1240
cache-control: public, max-age=86400

One system for page caching

The most reliable setups follow one principle: a single system controls how HTML pages are cached and served, and every other layer handles a different job.

• One page-caching system: either your host’s server-level cache or a single cache plugin, not both. This is the layer that stores prebuilt HTML and skips database queries and PHP execution on every request. It owns HTML generation, expiration, and purging.
• A CDN sits on top of that, serving static assets from the closest node to each visitor. For most setups, the CDN should pass HTML requests through to your page-caching system rather than caching HTML independently.
• Browser cache handles the rest: static files stored locally on the visitor’s device so repeat visits don’t re-download assets.

When page caching lives in one place, purging works reliably, expiration rules are consistent, and there’s no ambiguity about which version of a page is being served. The problems described earlier almost always trace back to two systems both claiming ownership of the HTML response.

An integrated setup is one where page caching, CDN, and frontend optimization are built to work together under a single system, instead of being assembled from separate plugins and services that each manage their own cache. That design removes the coordination problem before it can start, because ownership of each job is decided in advance rather than negotiated at request time.

SiteGround’s stack is built this way, and it works precisely because each layer has one job and doesn’t reach into another’s:

• SuperCacher runs three separate caches at the server level: NGINX Direct Delivery for static files, Dynamic Cache that serves full HTML pages from RAM, and Memcached for object and database queries. The HTML conflict this article is about lives in that Dynamic Cache layer, and only one system owns it.
• Speed Optimizer is the connector between Dynamic Cache and WordPress. It triggers autopurge when you update content, manages cache exclusions, and handles frontend optimization like minification and lazy loading. That autopurge coordination is what makes purging reliable, rather than something you do by hand across disconnected layers.
• SiteGround CDN (CDN 2.0) sits in front, using anycast routing across Google’s network edge to serve each visitor from the nearest location instead of passing every HTML request back to origin.

[86]

For the majority of WordPress sites, an integrated stack like this solves the most common caching problem by design: multiple disconnected systems fighting over the same HTML response.

How to audit your cache setup

You don’t need specialized tools to evaluate your caching stack. A plain review of what’s active, where page caching overlaps, and what symptoms it causes is usually enough to find the problem.

Step 1: List all cache layers

Document every caching mechanism active on your site:

• Caching plugins installed in WordPress (and whether page caching is enabled in each)
• CDN services connected to your domain (and whether they cache HTML, not just static assets)
• Server-level caching provided by your hosting
• Browser cache rules set through HTTP headers or your .htaccess file

Step 2: Find duplicate page caching

From your list, identify how many systems independently cache full HTML pages. This is the specific overlap that causes problems:

• More than one plugin with page caching enabled
• A plugin generating static HTML while the server cache already does the same
• A CDN caching HTML responses while a plugin or server cache also handles page caching

Overlap in static asset caching (CSS, JS, images) is generally harmless. Your audit should focus on which systems control the HTML response.

Step 3: Test by disabling one layer at a time

Once you’ve identified duplicate page caching, use a simple testing loop:

1. Disable page caching in one system (start with the one you suspect is redundant).
2. Purge all remaining caches (server, CDN, browser).
3. Test the page: check load time, verify content freshness, and inspect response headers.

If performance stays the same and content updates appear correctly, that layer was redundant. If load times increase, re-enable it and test disabling the other system instead. Repeat until only one system controls page caching, and keep the one that integrates best with your hosting and CDN.

When more complexity makes sense

Not every site runs best on a minimal setup. Additional caching layers are justified when:

• High-traffic global sites need granular control over how and where content is cached across multiple regions, languages, or regulatory requirements.
• Custom infrastructure, such as dedicated servers, containerized environments, or multi-server clusters, calls for purpose-built strategies like object caching with Redis or Memcached, edge-level logic, and tiered CDN configurations.
• Advanced edge caching pushes dynamic logic closer to the visitor by processing requests at CDN nodes rather than routing them back to the origin server.

The difference between these setups and the accidental complexity described earlier isn’t the number of layers. It’s the intent behind them. Each layer exists for a documented reason, follows strict rules, and stays clearly separated from the others. Page caching is still controlled by one system; the additional layers handle different jobs.

Fewer conflicts, faster sites

Most caching-related performance issues aren’t caused by too little caching or too many cache layers. They’re caused by a specific, fixable problem: more than one system trying to control full-page caching at the same time. Fix the duplication, keep one system in charge of HTML, and let the other layers do what they’re designed to do. The result is a setup that’s faster to maintain, easier to debug, and more consistent for every visitor.

If you’d rather not assemble and police those layers yourself, an integrated stack handles the coordination for you. SiteGround Web Hosting ships server-level page caching, a built-in CDN, and frontend optimization that already know about each other, so one system owns the HTML response and purging stays predictable.

FAQ