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.
▶ The whole install in 4 minutes 23 seconds, narrated, with captions — including the cache work that is unique to SiteGround, and the Anti-Bot blocker that stops Claude connecting.
The shape of it. SiteGround uses its own panel, Site Tools, rather than cPanel. And it asks one job of you that no other host does: taming its cache. Skip that one, and the install will feel haunted.
The ordinary start. Run the preflight check, then in Site Tools open File Manager, go into public_html, upload the PageMotor zip and extract it there. You should end up with pagemotor.php, a lib folder, and config-sample.php. If you got a single folder called pagemotor instead, move everything inside it up one level.
The SiteGround part. Every site runs a full-page cache called Dynamic Cache. It is on by default, there is no off switch in Site Tools, and its only built-in manners are for WordPress and Drupal. Everything else, PageMotor included, gets cached like an ordinary page for up to twelve hours. That includes the install screen, the admin area, and the login.
The kill switch. In public_html, edit or create .htaccess, and set Cache-Control to private at the very top. Then flush the cache in Site Tools, under Speed, Caching, Dynamic Cache. The flush is not optional: SiteGround only applies .htaccess caching changes after one. To check it worked, load any page and look at the x-proxy-cache header. BYPASS or MISS is what you want. HIT means the cache is still answering.
The database. SiteGround chooses the names for you: create the database and it generates one, create the user and that is generated too, with the password shown exactly once in a notice, so copy it now. And here is the step nearly everyone misses: a freshly created user has access to nothing. Go to Manage Access, pick your database, and give it all privileges, or PageMotor is turned away at the door.
The rename. config-sample.php becomes exactly config.php, and that rename is what switches PageMotor on. Put the three generated values into DB_NAME, DB_USER and DB_PASSWORD. DB_HOST stays localhost.
Finishing. Flush the cache, visit your site, then go to /admin/ and create your admin user. And straight after creating it: flush the cache again, clear your browser's cookies for the site, and only then log in. That one-two is what prevents the login loop.
“The user login cookie was not created!” Your browser really did get the cookie. The problem is the next page, which the cache answers with a copy saved before you logged in, so PageMotor never runs and never sees it. Break the loop in order: log out or close the tab, flush Dynamic Cache, delete the site's cookies, then log in again. On SiteGround, when in doubt, it is the cache.
SiteGround only. If you try to connect Claude to the site, SiteGround's Anti-Bot AI blocks the sign-in handshake, and you cannot fix it yourself. It parks a challenge under /.well-known/, which is exactly where PageMotor publishes the documents Claude has to read. Three things make it hard to spot. It answers 202, a success code, so error-hunting checks call the site healthy. It is keyed to the requesting IP, so your own browser sees the correct JSON while Claude is challenged. And it leaves /mcp/ alone, which sends people hunting inside PageMotor for a fault that is not there. Only a SiteGround support ticket lifts it.
pm-preflight.php,
upload it into the same folder you are about to install into, then open
yourdomain.com/pm-preflight.php in your browser. It tells you in plain English
whether this host can run PageMotor: the PHP version, any missing extensions, whether PHP can
write config.php for you, and whether the files landed in the right folder. It is
read-only, it never asks for a password, and it is deliberately written to run even on very old
PHP, so it reports an out-of-date PHP version instead of failing silently on it. Delete the file
once you have read the report.
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).
In practice, connecting takes about a minute. In a browser at claude.ai:
https://your-site.com/mcp/, all lower case, trailing slash included.Then simply talk to it: “what pages do I have”, or “create a contact page”. A free Claude account is enough and allows one custom connector; Pro, Max, Team and Enterprise allow more.
You do not need to test any of those requirements 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.