A plain-English walkthrough for SiteGround's Site Tools, including the one job SiteGround makes you do that other hosts do not: taming its cache.
Use this guide with any AI assistant
Download it as a prompt file, paste it into Claude, ChatGPT, Gemini or any LLM, and it will walk you through every step interactively.
public_html, your site's folder..zip. (SiteGround's File Manager has no upload size limit, so the zip goes up in one piece.)public_html.pagemotor.php, a lib folder, and a file called config-sample.php sitting in public_html. (If extracting gave you a single folder called pagemotor instead, open it, select everything inside, choose Move and move it all into public_html, then delete the empty folder and the zip.) Good. We use that sample file in step 4.SiteGround runs a full-page cache (Dynamic Cache) on every site. It is on by default, there is no off switch in Site Tools, and its only built-in manners are for WordPress and Drupal. Anything else, PageMotor included, gets cached like an ordinary page for up to 12 hours: the install screen, the admin area, even the login. Skip this step and the install will feel haunted: pages that refuse to change, an admin screen that will not appear, a login that goes round in circles.
public_html for a file called .htaccess. If it exists, right-click โ Edit; if not, create it (New File).# Temporary while installing PageMotor: stops SiteGround's
# full-page cache serving stale copies of your pages.
<IfModule mod_headers.c>
Header set Cache-Control "private"
</IfModule>
x-proxy-cache response header (browser dev tools โ Network, click the page request). BYPASS or MISS is what you want. HIT means the cache is still answering; flush again.PageMotor keeps your content in a database. SiteGround does this differently from cPanel hosts: it chooses the names for you.
dbabc123xyz); you do not get to choose it.This is the file that connects PageMotor to the database you just made.
config-sample.php next to pagemotor.php.config.php. This rename is the step that switches PageMotor on.config.php and choose Edit.DB_NAME, DB_USER and DB_PASSWORD. Leave the rest as they are, then Save.Here is what the database section of your config.php should look like once filled in. Edit the existing lines to match, using the values Site Tools generated for you; you are changing three values, not pasting this block in:
// Database connection info:
define('DB_NAME', 'dbabc123xyz'); // the generated name from Site Tools
define('DB_USER', 'the-generated-username'); // from the Users tab
define('DB_PASSWORD', 'the-password-from-the-notice');
define('DB_HOST', 'localhost'); // correct for SiteGround
define('DB_CHARSET', '');
define('DB_COLLATE', '');
define('DB_TABLE_PREFIX', 'pm_');
define('DB_FLAGS', '');
define('PM_HTML_CHARSET', '');
config.php (not config-sample.php, and not config.php.txt), and it must sit in the same folder as pagemotor.php.yoursite.com/admin/ and create your admin user.The step 2 kill switch turns SiteGround's page cache off for everyone, which is a perfectly fine place to stop for a small site; it will still be quick. If you want visitors to get cached pages for speed, swap the kill switch for a scoped rule that keeps the cache away from the admin area only:
# Cache public pages, but never the PageMotor admin.
<If "%{THE_REQUEST} =~ m#/admin#">
<IfModule mod_headers.c>
Header set Cache-Control "private"
</IfModule>
</If>
PageMotor speaks MCP natively, so once your site is up you can connect Claude Code or Claude.ai to it and let Claude build pages, manage content and run plugins for you. The connection asks a little more of a host than serving pages does. Four things must be true: the Authorization header must reach PHP intact, PageMotor must be allowed to answer its dynamic /.well-known/ routes itself, PHP's clock must be on UTC, and nothing may redirect Claude's POST to /mcp (the trailing-slash trap).
You do not need to test any of that by hand. Install EP Host Check and read its MCP / Claude connection rows: since v1.2.0 its five checks cover all four of those from your admin panel, no working Claude connection required, each with a plain fix. There is a fifth cause on this host that no on-server check can see, and it is the next box. If a row fails, or the connection misbehaves anyway, the MCP troubleshooting guide has the exact diagnostic and fix for every verified cause.
/.well-known/, the same place PageMotor publishes the discovery documents Claude must read, so Claude gets a challenge page instead of JSON and sign-in never completes.
Three things make this one hard to spot. It answers HTTP 202, which is a success code, so any check looking only for errors calls the site healthy. It is keyed to the requesting IP, so your browser is trusted and sees the correct JSON while Claude, arriving from a datacentre, is challenged every time. And it leaves /mcp/ alone, which sends people hunting inside PageMotor for a fault that is not there. EP Host Check runs on the server itself, and SiteGround does not challenge its own loopback, so it cannot see this one either.
The fingerprint, from outside the host: 202 plus content-type: text/html plus an sg-captcha: challenge header. No Site Tools switch and no .htaccess line reaches it, because the wall sits in front of Apache. Only a SiteGround support ticket can lift it. Ask them to exempt /.well-known/oauth-*, /.well-known/api-catalog, /api/ and /oauth/ from bot protection, and say 202 rather than 404 or they will go looking for a missing file. Full diagnosis in section 6g of the MCP troubleshooting guide.
Authorization header before PHP ever sees it. The fix is one line in your .htaccess, ready to paste in section 6 of the troubleshooting guide.Open these only if you hit them. On SiteGround, when in doubt, it is the cache.
most commonYour browser really did get the cookie; you can even see it in dev tools. The problem is the next page: SiteGround's cache answers it with an old copy saved before you logged in, so PageMotor never runs and never sees your cookie. Break the loop in this order:
.htaccess and that you flushed after saving it.Same cause: the cache is serving an old copy of /admin/ from before PageMotor was ready. The giveaway is when a friend on a different connection can see the screen you cannot; that is the cache talking, not your install. Do the step 2 kill switch if you have not, flush Dynamic Cache, and reload. Check the x-proxy-cache header reads BYPASS or MISS, not HIT.
Flush Dynamic Cache in Site Tools. If a page still will not budge, look at its x-proxy-cache response header: HIT means the cache answered, so flush again and re-check your .htaccess rule from step 2 (and remember each .htaccess change itself needs a flush to take effect).
Almost always a config.php problem. Check the file is named exactly config.php (not still config-sample.php), that it sits next to pagemotor.php, and then read the real reason in Site Tools โ Statistics โ Error Log. If it says config.php "No such file or directory", this is your fix.
PageMotor reached the database step but could not get in. On SiteGround this is nearly always the privileges step:
DB_HOST is localhost on SiteGround.It ships inside the PageMotor download, right next to pagemotor.php. Two things to check: the files may have landed in a pagemotor subfolder when the zip extracted, in which case move everything in it up into public_html (see the note in step 1); and if the folder is genuinely empty, the zip did not extract completely, so repeat step 1.