How Rankbank reads your site

Nothing on your site is changed. Rankbank only looks.

That's worth saying first because "audit tool" makes people nervous. Rankbank has no write access to your website, never asks for any, and never posts, edits or deletes anything. A read is a sequence of ordinary page requests, the same ones a visitor's browser makes, and everything you see afterwards is worked out from what came back.

What a read does, in order

A read starts at your homepage and works outwards.

1. The homepage. Rankbank fetches it, reads the HTML, and records everything it finds.
2. Robots and sitemaps. It reads robots.txt and follows any Sitemap: lines in it, then tries /sitemap.xml directly, then follows any nested sitemaps a sitemap index points at.
3. Your internal links. From there it follows the links it found, breadth-first, so pages one click from home are read before pages two clicks away.

It stops when it hits the page limit or runs out of pages within the depth limit, whichever comes first.

The crawler identifies itself as RankbankSiteIntelligenceCrawler/1.0. If you run a firewall, a WAF, or bot protection in front of your site, allowlist that user agent or the read will come back empty.

What gets recorded for each page

For every page it reaches, Rankbank stores:

• The title, the main heading or headings, and the meta description
• Word count
• Depth, meaning how many clicks from the homepage it took to get there
• Whether the page is indexable, and any redirects it went through on the way
• The canonical tag, if there is one
• Every internal link on the page, with its anchor text and where on the page it sat: header, navigation, hero, card, body-contextual, sidebar, footer, or logo
• Images, and which of them have no alt text
• Open Graph tags and any structured data types declared

The placement of a link is the part most tools skip, and it's the reason Rankbank can tell the difference between a page that's genuinely linked and one that only appears in your footer. A link inside a real sentence and a link repeated on every page of the site are not the same signal, so they aren't recorded as the same thing.

Pages that fail to load are recorded as failures. They don't stop the read.

Starting a read

The Read this site again panel at the bottom of the Overview page is where you start one. The button reads Start the audit the first time and Read it again after that.

While it's running you get a panel headed Reading your site now, saying: "This can take a few minutes on a large site. You can leave this page — it keeps going, and the count below updates on its own."

The live progress line under the button reads {n} read · {n} found, and adds · {n} unreachable once something has failed. "Read" is pages successfully fetched, "found" is URLs discovered so far, and "unreachable" is pages that didn't load. On a healthy site "found" runs ahead of "read" for most of the run and the two converge at the end.

Limits

Under the button is a disclosure labelled Limits, with the note "Only if you want to cap the run — the defaults cover almost every site."

How many pages to read defaults to 100. The description says "Stop after this many pages. {n} is the most your plan allows." The ceiling comes from your plan, and the field will not let you go above it.

How deep to go defaults to 2, with a maximum of 8. Its description: "How many clicks from the homepage to follow. 2 covers most sites."

Depth 2 sounds shallow but it isn't. Depth 0 is your homepage, depth 1 is everything the homepage links to, depth 2 is everything those pages link to. On a normally structured site that's your whole navigation plus a layer of real content. Raise it when you have a deep blog archive or a category tree several levels down, and expect the read to take longer.

If you raise the page limit, raise it in steps. A first read of 100 pages tells you most of what a first read of 500 would, and it comes back in a fraction of the time.

What happens the moment a read finishes

A finished read kicks off a chain of work, in this order, with no input from you:

1. Structural issues are generated. Broken links, missing titles, orphan pages and the rest. These become the Problems to fix page.
2. Health is scored. Each family of problem takes points off proportionally. See the site health score.
3. Your pages are grouped by topic. Which pages cover what, which topics have a lead page and which don't. See topics and content ideas.
4. Findings are re-evaluated. Every rule in the catalog runs against the new data. Findings that are no longer true get marked stale automatically, and new ones appear. See everything Rankbank looks for.
5. You get a notification. In the app, on the bell.

The notification is Your site audit finished, with the line "We read {n} pages and found {n} things worth fixing." If the read stopped early you get Your site audit stopped early instead, filed as important rather than informational. Only the person who started the read is notified. See how Rankbank tells you things.

When a read goes wrong

Three failure states, each with its own message.

"We couldn't reach your site" means every page Rankbank tried failed to load. The message continues: "Every page we tried failed to load. Check the website address in your site settings and that the site is online, then try again." In practice this is nearly always one of three things: a typo in the address stored on the site, a site that's actually down, or bot protection turning the crawler away at the door.

"Rankbank could not finish reading your site" means the read started and stopped partway: "Something went wrong partway through. Try again — if it keeps failing, the site may be blocking automated visitors."

"Could not start" appears when the request to begin never got off the ground, with whatever the server said underneath. Usually a permissions problem or a run already in progress.

A finished read reports itself with Finished reading your site: "{n} pages read, and {n} pages that could not be reached. The results below are up to date." A handful of unreachable pages is normal on most sites and usually means links pointing at pages that no longer exist. Those turn into broken-link problems you can act on, which is the point.

Reading it again

A good trigger is "after I shipped something". Fix a batch of problems, read the site, then check the Since your last read panel on the Overview to see the change reflected. That comparison is what makes the work legible a month later, and it's the whole basis of past reads and history.

If you only want the findings recalculated rather than the whole site re-read, the Re-check button in Do these three next does exactly that, using the data from the last read. It's much faster, and it's the right button when you've dismissed a few findings and want the list to settle.