Render is the step that turns the current experiment specification into deployable page files on disk, without pushing them to a live server. It produces the exact output an eventual deploy would ship, so you can inspect it first.
| Term | Render |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Batch Render |
| Where it appears | Experiments → Render |
What it means in RankGear
Inside an experiment, Render sits between designing changes and publishing them. When you run it, RankGear reads the current specification — the pages, edits, and settings the experiment defines — and writes finished page files locally. Nothing leaves your machine and nothing on the live site changes. The result is a concrete set of files you can open, diff, and confirm before any deployment target is touched. Because it runs as a batch over every page in scope, it is also called Batch Render.
How to interpret it
Treat Render as a dry run whose output you are meant to verify. If a page fails to render, read the visible status and diagnostics before reacting: a timeout or a dropped connection points to a transient problem worth one bounded retry, while a rejected credential or a malformed target points to configuration that a retry will not fix. Use the credential test to tell those apart rather than guessing. A clean render means the files are ready; it does not by itself mean they are live.
Example
You finish an experiment that rewrites the title tags and intro copy on twelve product pages, then run Render. Eleven pages write cleanly to the output folder. One times out reaching a remote asset and is granted a single longer retry, after which it succeeds. Had one page instead failed with an authorization error, Render would have stopped it rather than repeating a paid or rate-limited call, and the status would flag credentials to fix before you deploy.
Important considerations
- Render builds files; it does not publish them. A successful render is a checkpoint, not a live change — deploying is a separate, deliberate step.
- Credentials and remote publishing targets deserve care. Connection tests should be read-only wherever possible, and any secrets involved must stay redacted in logs and diagnostics.
- Distinguish transient failures from invalid configuration using the status, diagnostics, and credential test — retry only what a retry can actually fix, so you avoid repeated failed or billable calls.
- Rendering pages is a production and reliability step, not a ranking signal. It has no bearing on how any search engine scores the resulting pages.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.