The Remote Upload Path is the directory on a remote server where RankGear writes rendered experiment pages or a built report site when it publishes.
| Term | Remote Upload Path |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Upload Path, Remote Path |
| Where it appears | Domain tables |
What it means in RankGear
You set the Remote Upload Path per domain in the Domain tables. It is the target folder on a connected host where RankGear deposits the files it publishes — whether that is a set of rendered experiment pages or a fully built report site. The value is a location, not a measurement: it tells RankGear which directory on the server should receive the output, and it stays paired with that domain’s connection credentials so every publish lands in the right place.
How to interpret it
Read the Remote Upload Path alongside the domain’s connection status and the publish diagnostics rather than in isolation. When a publish fails, the path itself is often correct while the connection or the credentials are at fault, so use the status lamp, the diagnostic messages, and a read-only credential test to separate a transient hiccup from a genuine misconfiguration. A timeout is usually worth a single bounded retry; an authorization failure or a plainly wrong path should stop rather than repeat. A path that points at the wrong directory will publish without error but to the wrong place, so confirm it matches the web root or subfolder your site actually serves.
| Symptom | Read it as |
|---|---|
| Page timed out mid-upload | Transient — allow one bounded retry |
| Authorization rejected | Invalid credentials — stop and fix, do not retry |
| Files published but not visible on the site | Wrong path — point it at the correct web root |
Example
You configure a domain to publish a built report site to /public_html/reports on its host, and RankGear writes the generated files to that Remote Upload Path. If one page times out mid-upload, RankGear may make a single longer, bounded retry. If the server rejects the credentials, the publish stops immediately instead of repeating a failing — and possibly paid — call.
Important considerations
- Credentials and remote publishing targets require care: keep secrets redacted in logs and diagnostics, and prefer read-only checks when testing a connection.
- A valid-looking path aimed at the wrong folder still reports success — it simply publishes to the wrong location, so verify it against the server’s actual web root.
- Distinguish a transient failure from invalid configuration before retrying, so a bad path or bad authorization does not trigger repeated wasted calls.
- The path is a publishing target, not a ranking signal: it controls where your pages land, not how they perform in search.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.