Connect GitHub
For sites whose pages live in a repository, RankGrep opens pull requests instead of writing to a database.
On this page
If your website is built from a repository, RankGrep can still fix it. Instead of writing to a database, every approved fix becomes a pull request.
How it works
- Click Connect GitHub on the Connections page. GitHub asks which repositories to grant RankGrep access to. Choose only the one for this website.
- Once a fix is approved, RankGrep creates a branch named
rankgrep/<id>, commits the single change, and opens a pull request with the before and after in its description. - You review and merge, with the Merge pull request button in the repair preview or in Change history, or on GitHub. RankGrep never merges on its own. Nothing is live until a person clicks the button.
- The merged change goes live with your site's next deploy, usually within a few minutes. The next audit confirms it on the live page.
Which file RankGrep edits
RankGrep edits the file that sets the page's title, and only when it can match that file to the page by the title your last audit saw. If it cannot make that match, the repair is shown as guidance to apply by hand rather than as a change RankGrep will commit.
On a Next.js site the title in the page file is often shorter than the one a visitor sees. A layout can add a fixed prefix or suffix to every page title, such as | Brand. RankGrep understands that: it matches the page correctly, writes only the page's own part of the title, and keeps the full rendered title within the length limit. A page that sets title: { absolute: "..." } opts out of the layout's addition, and RankGrep treats it that way too.
A page that builds its title in code, rather than as a plain string in export const metadata, is out of reach. RankGrep says so in the repair preview. Writing the title as a plain string in the page file is enough to make it repairable.
Headings and opening paragraphs on a Next.js site are edited by the text itself. RankGrep looks for the exact sentence your last audit saw, in the page's file, in the components that file imports, and in the content those files define, such as a list of FAQ entries, and edits it only when it appears exactly once. It also notes where the text sits, so a paragraph that answers a question is rewritten as an answer to that question, not as a general introduction. The pull request shows which file changed; when that file is a shared component, the repair preview says so, because other pages using it change too. A heading that is split across nested elements, or text that appears more than once, is left as guidance.
What RankGrep can see and do
The GitHub App asks for three permissions and nothing else:
| Permission | Why |
|---|---|
| Contents: read and write | Create the branch and commit the change |
| Pull requests: read and write | Open the pull request |
| Metadata: read | Required by GitHub for every app |
RankGrep stores no long-lived token. It holds only the installation id, and GitHub issues it a one-hour token each time it needs to act. Removing the installation under GitHub → Settings → Applications ends access instantly.
Undo
Every action on a GitHub change sits in the ⋯ menu on its row in Change history. While the pull request is open, Close pull request closes it and deletes the branch, and nothing on your site changes. Once it is merged, Revert change opens a second pull request that puts the original value back and merges it, so the site changes back with its next deploy. RankGrep only reverts its own value: if the field has been edited since, it stops and asks you to revert by hand. Preparing a fresh proposal for the same page also closes the earlier pull request: each page has one repair at a time, and the new one replaces the old.
Why there is no deploy problem here
The repository is the source of truth. A fix that lands as a merged pull request is in every future build, so local changes and RankGrep's changes never diverge. The deploy precautions in this documentation are for WordPress sites.