Deploys

A deploy is a dated release of your site. Recording deploys is what lets RankDebug line a drop up against the release that came before it, and check the site right after each release while the cause is still fresh.

There are two ways to record them. Connect the repository with GitHub or GitLab and RankDebug reads production deploys on its own, or report each deploy from your CI with one request, as below. Both can run side by side: a deploy is identified by its environment and commit, so the same release reported twice lands on one record.

Report a deploy from CI

Create an API key on the API Keys page with the Deploys permission. A key with only this scope can record deploys and read nothing back, which makes it safe to store in CI. If you bind the key to this workspace, requests do not need to name the workspace.

Then add one request after your deploy step:

curl -X POST https://api.rankdebug.com/v1/deploys \
  -H "X-API-Key: $RANKDEBUG_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"commitSha\":\"$COMMIT_SHA\",\"environment\":\"production\"}"

Fields

changes is a list of up to 500 files. Each has a path, a category and up to 50 signals, where a signal is a kind (for example canonical or noindex), a change of added or removed, and an optional line. Send paths and signal names only, never code. A deploy with no changes is still recorded and still checked.

The response is 201 with the recorded deploy. Reporting the same environment and commitSha again updates that record instead of creating a second one. The full endpoint reference is on Deploys API.

What happens after a production deploy

When a deploy to the production environment is recorded, or its deployedAt time changes, RankDebug queues two things:

• A site check about two minutes later, giving the new build time to be served. It compares the site against the check before the deploy.
• A site crawl about five minutes later. It is skipped, not failed, when a crawl is already running or the balance cannot cover it.

Deploys to other environments are recorded for the timeline but trigger neither.

Reading a deploy

The Deploys page lists every deploy with its commit, environment, message and the result of its site check. Opening one shows:

• Site Check: what got worse on the site since the check before the deploy, each finding with the clicks at stake on its page and, where the release's changes point to it, a likely cause.
• Search Impact: Search Console clicks and impressions for equal windows before and after the deploy, up to seven days each side. When findings name pages, the pages they name are compared against the rest of the site, so you can see whether the affected pages moved apart from everything else. This fills in once Search Console has data for the days after the deploy.
• Changed Files: the SEO-relevant files the release changed, when the deploy came with them.

Through the API, a deploy also carries the crawl that followed it and the crawl findings that are new since the crawl before, each with a likely cause in the same way.

The Overview chart marks each deploy day, so a change in clicks can be read against the releases around it.