Slow-Page Safety Retry is a single longer rendering attempt RankGear makes after a page returns an empty hard timeout or a provisional load failure, run within the same bounded safety limits so a genuinely slow page still gets one fair chance to render.
| Term | Slow-Page Safety Retry |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Longer Page Retry |
| Where it appears | Analysis Run, On-Page Audit, and Bulk Runs |
What it means in RankGear
When RankGear fetches and renders a page, it works under a fetch budget so a single unresponsive URL cannot stall a whole run. If a page hits that hard ceiling with nothing usable returned, or the initial load fails only provisionally, the run does not immediately mark it dead. Instead it grants one Slow-Page Safety Retry: the same page is rendered again with a longer allowance, still capped by the established safety limits. You see the outcome reflected in the run status and per-URL diagnostics for Analysis Run, On-Page Audit, and Bulk Runs, where a page that succeeded on the second attempt is treated as a normal result rather than a failure.
How to interpret it
Read this as RankGear separating “slow” from “broken.” A retry firing tells you the first attempt timed out with no content, not that the page is misconfigured; a page that renders on the retry is fully valid data. What the retry deliberately does not do is loop. It is one longer attempt, not open-ended re-polling, so a URL that still returns nothing after the retry is a real fetch failure worth investigating rather than a timing fluke. When you are triaging a failed URL, check the visible status and diagnostics first: a transient slow render behaves differently from an authorization or credential problem, and only the former is what this retry is meant to rescue.
| Situation | What the retry does |
|---|---|
| Empty hard timeout or provisional load failure | One longer rendering attempt, within bounded limits |
| Page renders on the second attempt | Counted as a normal, valid result |
| Still empty after the retry | Recorded as a genuine fetch failure, no further loops |
| Authorization or credential failure | Stops without repeated paid calls |
Example
You queue a Bulk Run across 40 competitor URLs. One of them is a heavy, script-laden landing page that does not finish rendering before the fetch budget expires, so the first attempt returns empty. RankGear applies a Slow-Page Safety Retry, gives that single URL a longer allowance, and the page renders in full the second time, so it lands in your report as ordinary data. In the same run a different URL sits behind an authorization wall; that one fails on the first response and is not retried, because repeating the request would only burn time and paid calls without changing the outcome.
Important considerations
- The retry is bounded and singular by design: one longer attempt, not continuous re-polling, so it cannot let a slow site hang an entire run.
- It targets timing and provisional load failures only. Authorization and credential errors are not retried, because the problem is configuration, not speed.
- Where the retry touches credentials or remote publishing targets, tests should stay read-only where possible and secrets must remain redacted in logs and diagnostics.
- A page that renders on the retry is data of the same quality as a first-attempt render; a page that fails after it is a real failure to investigate, not noise.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.