Publish or Update uploads a built Site Builder folder to a remote host so the matching HTML pages, index file, and sitemap are created if they are missing or replaced if they already exist.
| Term | Publish or Update |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Publish, Update Site |
| Where it appears | Site Builder → Domains |
What it means in RankGear
Publish or Update is the action that pushes a locally built site live. After Site Builder generates the folder of pages for a domain, this step connects to the configured remote target and writes each file into place: the HTML documents, the site index, and the sitemap. A first run creates those files; a later run overwrites the ones that changed, which is why the single control covers both the initial publish and every update after it. You reach it from Site Builder → Domains, alongside the credentials and target settings for the site you are pushing.
How to interpret it
Treat the result as a report on the transfer, not just a success or failure light. The visible status, the diagnostics, and the read-only credential test together tell you which kind of problem you are looking at. A page that times out mid-transfer is usually a transient network issue and is worth a retry; an authorization or permission error points to invalid configuration and will keep failing until the credentials or target path are corrected. Reading the status before you retry is what separates a quick recovery from a loop of the same failed upload.
Example
You finish building a five-page site for a client domain and click Publish. Four pages, the index, and the sitemap upload cleanly, but one page reports a timeout. Because a timeout is transient, RankGear can give that page one bounded longer retry and it completes on the second attempt. Later, an authentication failure on a different domain stops immediately rather than hammering the host with repeated attempts, so you fix the stored credentials and publish again.
Important considerations
- Credentials and remote publishing targets need care: a wrong host, path, or key sends files to the wrong place or fails outright.
- Connection tests should stay read-only where possible so verifying access never alters or deletes remote files.
- Secrets stay redacted in logs and diagnostics; the interface should never expose stored passwords or keys in plain text.
- Distinguish transient failures from configuration errors before retrying, so a bounded retry recovers real network blips without repeating doomed calls.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.