ElmsPark Guides
PageMotor Setup Guide

Installing PageMotor on SiteGround

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.

โฑ ~20 minutes ๐Ÿงฐ One copy-paste, no real coding โš  Cache taming required
Before you start, have these ready: a SiteGround hosting account, the PageMotor files (the .zip you downloaded), and the name of your website. SiteGround uses its own panel called Site Tools, not cPanel, and it is per-site: open it for the right website via Client Area โ†’ Websites โ†’ Site Tools.

On a cPanel host instead? Use the Bluehost, HostGator or GoDaddy guide; the steps there are simpler.

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.

Download as LLM prompt

▶ 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.

Read the narration instead

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.

Worth thirty seconds before you start: run the preflight check. Download 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.

1Put PageMotor on your site

  1. In Site Tools, open Site โ†’ File Manager and go into public_html, your site's folder.
  2. Click the File Upload icon in the toolbar and upload your PageMotor .zip. (SiteGround's File Manager has no upload size limit, so the zip goes up in one piece.)
  3. Right-click the uploaded zip and choose the Extract option (the exact wording can vary), extracting into public_html.
When it is done you should see 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.

2Tame SiteGround's cache

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.

  1. In File Manager, look inside public_html for a file called .htaccess. If it exists, right-click โ†’ Edit; if not, create it (New File).
  2. Paste this at the very top and save:
# 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>
  1. Now flush the cache once: Site Tools โ†’ Speed โ†’ Caching โ†’ Dynamic Cache, then the Flush Cache action. SiteGround only applies .htaccess caching changes after a flush, so this part is not optional.
How to check it worked: load any page of your site and look at the 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.

3Create your database

PageMotor keeps your content in a database. SiteGround does this differently from cPanel hosts: it chooses the names for you.

  1. In Site Tools, open Site โ†’ MySQL. On the Databases tab, click Create Database. SiteGround generates the database name (something like dbabc123xyz); you do not get to choose it.
  2. Switch to the Users tab and click Create User. The username and password are generated too, and the password is shown once, in a notice. Copy it somewhere safe now.
  3. Still under Users, find your new user and choose Manage Access (or Add New Database): pick your new database, choose All Privileges, and confirm.
The step nearly everyone misses on SiteGround: a freshly created user has access to nothing. If you skip the Manage Access part, PageMotor will be turned away at the door. You will need three things in the next step: the generated database name, the generated username, and the password from the notice.

4Fill in config.php

This is the file that connects PageMotor to the database you just made.

  1. In File Manager, find config-sample.php next to pagemotor.php.
  2. Right-click it and choose Rename. Rename it to exactly config.php. This rename is the step that switches PageMotor on.
  3. Right-click config.php and choose Edit.
  4. Put the three generated values into 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', '');
Two things to double-check: the file must be named exactly config.php (not config-sample.php, and not config.php.txt), and it must sit in the same folder as pagemotor.php.

5Finish in your browser

  1. Flush Dynamic Cache once more (Site Tools โ†’ Speed โ†’ Caching), so your first visit is answered by PageMotor and not by an old cached copy.
  2. Visit your website. On this first visit PageMotor quietly sets up its content for you.
  3. Go to yoursite.com/admin/ and create your admin user.
  4. Straight after creating it: flush Dynamic Cache again, and clear your browser's cookies for the site, then log in. This one-two is what prevents the login loop described in the troubleshooting below.
That is it. You are in. If the login misbehaves anyway, it is the cache; the first troubleshooting item below walks you out of it.

6Give your visitors the cache back (optional)

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>

Connecting Claude from this host

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:

  1. Go to Customize → Connectors (straight there: claude.ai/customize/connectors).
  2. Click +, then Add custom connector.
  3. Give it any name you like. For the URL, use your site’s connector address: https://your-site.com/mcp/, all lower case, trailing slash included.
  4. Click Add. Claude sends you to a sign-in page on your own site. Log in with your PageMotor admin account and approve it.
  5. Start a new chat, click the + at the lower left of the message box, hover Connectors, and switch yours on.

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.

SiteGround onlySiteGround's Anti-Bot AI blocks the sign-in handshake, and you cannot fix it yourself. It parks a CAPTCHA under /.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.

The usual offender on shared hosting is the first item: Apache running PHP as FastCGI drops the 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.

If something is not working

Open these only if you hit them. On SiteGround, when in doubt, it is the cache.

I see "The user login cookie was not created!"

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:

The admin screen will not appear on a fresh install

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.

My changes do not show up

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).

I see "HTTP ERROR 500" or a blank white page

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.

The log says "Access denied" or "MySQLi Connection Error"

PageMotor reached the database step but could not get in. On SiteGround this is nearly always the privileges step:

I cannot find config-sample.php

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.

๐Ÿ“ง Will your site send email? Contact forms, sign-ups and password resets need a proper mail service or they land in spam. Follow the companion guide: Set up reliable email with Mailgun.