Deploying a React SPA to SiteGround Without Breaking SEO

Plenty of businesses already pay for SiteGround to host their WordPress site or company email, and when they build a React app the natural question is: can I just put it here too? Yes — you can host a React single-page app on SiteGround shared hosting, and it works well for the right kind of app. But two things trip people up: the routing (refresh a page and you get a 404) and the SEO (a client-rendered SPA can look empty to Google if you are not careful).

This guide covers both, start to finish, so your React app deploys cleanly and stays visible in search.

First, is a SPA on SiteGround the right choice?

Be honest about what your app is. A React SPA on shared hosting is a great fit for a dashboard, an internal tool, or a marketing-light web app where users are logged in and SEO does not matter much. It is a poor fit for a content site that lives or dies on organic search — a blog, a store, a directory. Those need server-side rendering, and that points you toward Next.js on a platform like Vercel rather than static files on SiteGround.

If most of your traffic comes from Google and every page needs to rank, read the SEO section below carefully before committing — you may be better served by a different architecture. For a logged-in app, SiteGround is perfectly capable.

Step 1: Build the production bundle

Your dev server is not what you deploy. Run the production build so your bundler (Vite or Create React App) outputs static, minified files:

npm run build

This produces a dist folder (Vite) or build folder (CRA) containing index.html, hashed JS and CSS, and your assets. Those files — not your source — are what goes on SiteGround.

Before you upload, set your production environment variables and API base URL. A hardcoded http://localhost:8000 baked into the bundle is the single most common reason a freshly deployed SPA loads but every request fails.

Step 2: Upload to the right folder

Log into SiteGround's Site Tools and open the File Manager (or connect over SFTP, which is faster for many small files). Upload the contents of your build folder — not the folder itself — into the correct web root:

• Primary domain: public_html
• Subdomain: the folder SiteGround created for it, for example public_html/app

After upload, index.html should sit directly in that web root alongside the assets folder. Visit the domain and the home screen should load.

Step 3: Fix client-side routing with .htaccess

Here is where most people hit the wall. Your home page loads, you click around and it works, then you refresh on /pricing or share that link — and SiteGround returns a 404.

The reason: React Router handles routes in the browser, but when you refresh, the browser asks the server for a real file at /pricing, which does not exist. SiteGround runs Apache, so the fix is an .htaccess file in your web root that redirects every request back to index.html and lets React take over:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]
</IfModule>

The two RewriteCond lines say "if the requested path is not a real file or directory, serve index.html." Real assets still load directly; everything else falls through to your app. If your app lives in a subfolder, set RewriteBase and the fallback path to match that folder.

Step 4: Force HTTPS and set caching

SiteGround issues a free Let's Encrypt certificate — enable it in Site Tools under Security. Then force HTTPS so no one lands on the insecure version, by adding this above the routing rules in the same .htaccess:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Because your JS and CSS filenames are content-hashed on every build, you can cache them aggressively for speed without risking stale files. A long cache lifetime on /assets and a short one on index.html is the standard pattern.

The SEO problem — and how to avoid breaking it

A pure client-rendered React app ships an almost-empty index.html; the content only appears after JavaScript runs. Google can render JavaScript, but it does it on a delay and imperfectly, and other crawlers (some social and AI bots) barely do it at all. If organic search matters, do not leave it to chance.

Here is how the options compare:

Practical steps that protect SEO on SiteGround:

• Set per-route meta tags with a head manager so each page has a real title and description, even before hydration.
• Prerender your public pages to static HTML at build time so crawlers get real content immediately.
• Add a sitemap.xml and robots.txt in the web root and submit the sitemap in Google Search Console.
• Use real links, not onClick navigation, so crawlers can follow them.

If after this you find search is still central to the business, that is your signal to move to a server-rendered stack. Our walkthrough on the last-mile deployment gap covers the environment and build issues that show up in any move like this.

Updating the app after it is live

Deployment is not a one-time event — you will ship changes. The clean workflow keeps you from breaking a live app. Build locally with npm run build, confirm the app runs from the built output (not the dev server) on your own machine, then upload the new files, replacing the old ones in the web root. Because your JS and CSS filenames are content-hashed, returning visitors get the new versions automatically instead of a stale cached bundle, while index.html stays small and refreshes quickly.

Two habits save you real pain here. First, keep a copy of the previous build so you can roll back in seconds if something looks wrong after upload. Second, never edit files directly on the server through the File Manager — that change exists nowhere in your source and disappears the next time you deploy. Treat the server as disposable output and your local repository as the single source of truth. For anything more complex than an occasional manual upload, a simple deploy script or a Git-based workflow removes the human error that causes most "I uploaded it and now it's broken" moments.

Frequently asked questions

Why does my React app 404 when I refresh a page on SiteGround? Because the server looks for a real file at that path and there isn't one. Add the .htaccess rewrite that sends all non-file requests to index.html so React Router can handle the route.

Can I run a Node backend on SiteGround too? SiteGround shared hosting is built for PHP and static files, not long-running Node servers. Host your React frontend there if you like, but put the Node API on a platform designed for it and point the frontend at that API's URL.

Is SiteGround good for SEO-critical React sites? Not on its own. A client-rendered SPA on shared hosting is weak for SEO. Prerender your public pages, or use a server-rendered framework, if ranking is important.

---

Want your React app live on SiteGround without the 404s and the SEO surprises? SprintX deploys and rescues React apps on every kind of host — with routing, HTTPS, and search visibility handled — on a fixed-scope quote you own. Get a deployment plan for your app.