How we audit our own site with Crawl Cove

This is the one audit on this site we are allowed to call a case study, because it is ours. Every third-party write-up in the teardowns is a plain crawl of a public site. Our own site is the only one where we can connect Google Search Console, so it is the only place we can show what the crawl looks like with ranking data on top of it: which crawled pages Google shows, which pages Google shows that the crawl did not reach, and which findings sit on pages that have impressions.

We ran it the way a customer would on day one: add the site, connect Search Console in one click, start a crawl, read the Overview.

The crawl

262 URLs, every one of them a 200. No redirects, no redirect chains, no fetch errors, no robots.txt surprises (robots.txt kept the crawler out of 3 account URLs, which is what it is there for). 256 of the 262 are HTML pages; the other six are files the site serves on purpose: two update feeds for the app, the changelog RSS, security.txt, one example PDF report and one CSV of research data. The crawler reached depth 6 and found nothing beyond it, so a depth limit of 12 was never touched.

What Search Console adds

With the property connected, the Search page lists 666 queries and 83 pages that had impressions in the 28 days to 27 October 2026, with the change against the previous 28 days beside each one. The Pages tab is the view we use most: it is the list of pages Google is actually showing, in impression order, so the question "which of our findings matter" has a number next to it.

Three cross-checks the crawl alone cannot do:

• Pages Google shows that the crawl missed. One: an old guide URL with 19 impressions in 90 days that now returns 404. It needs a redirect to the guide that replaced it. The app lists these under "Pages Google shows, your crawl missed" on the same tab.
• Crawled pages with no impressions. 77 of the 256 HTML pages had no impressions at all in the 90 days to 27 October. Some are meant to be invisible (login, register, account guides marked noindex); the rest are pages we have published and Google has not shown for anything yet.
• Findings on pages that have impressions. 15 pages with impressions carry an open finding. The biggest is /compare (1,462 impressions in 90 days) with a low AI-extractability score; the next is /seo-audit (472) with a title one character over 60.

The URL inspector asks Google directly for a page's index status. For the Screaming Frog comparison it came back "Submitted and indexed", 3,155 impressions and 2 clicks in 90 days, and a last Google crawl on 31 August 2026, two months before this audit. That date is the kind of thing you only learn by asking.

How we audit our own site: what the crawler told us to fix

251 open findings sounds like a lot. The Findings page splits them: 0 urgent, 25 improvements, 226 opportunities. The 226 are information-grade suggestions (internal link opportunities, AI answer structure) that we read as a backlog, not a to-do list. The 25 are the ones below.

1. Nineteen pages carry noindex

What it is: 19 HTML pages answer 200 with a robots noindex tag: login, register and forgot-password, plus 16 in-app help guides. Why it matters: noindex is sometimes an accident, and a page that is noindexed is also one Search Console will quietly stop showing. Here it is deliberate (the help guides duplicate the app's own help and the account pages should never rank), which is exactly why the check is high severity: it is a "confirm this on purpose" check, and we did.

2. One orphan page, and it is a sales page

What it is: the Black Friday deals page has zero internal links pointing at it. It is in the sitemap, so Google can find it, but no visitor can. Why it matters: an orphan page gets no link equity and no clicks from the rest of the site, and a seasonal offer page is the last place you want that. Fix: link it from the pricing page and the homepage once the offer goes live. See orphan pages for how the check works.

3. One slow response

What it is: /contact took 3,393 ms to answer, against a 3,000 ms threshold; the other 261 URLs were well under it. Why it matters: a single slow page is usually a single slow thing (here, a form page that is not edge-cached), and a response time measured by the crawler is the number Googlebot sees too.

4. Twenty titles over 60 characters and four meta descriptions out of range

What it is: 20 page titles run to 61 to 63 characters once the " | Crawl Cove" suffix is added, so they are cut in the search result. Our own rule is 60 including the suffix; the crawler enforces it better than we do. Four meta descriptions are missing (the three account pages) or too long (the Black Friday page, 177 characters). Why it matters: the title is the link in the result, and a cut title loses the keyword or the brand. The title tag checker measures the same thing for one page at a time.

5. Twenty-four pages at crawl depth 6

What it is: every page under /issues/ai/ and /issues/security/ sits six clicks from the homepage. Why it matters: Google crawls deep pages less often, and we have 17 impressions-earning pages in that section. Fix: link the /issues category pages from the features page and from each other.

Not flagged, and worth saying: 717 images, 0 missing alt text; no duplicate titles among indexable pages (the blog's six pagination URLs share a title, and the crawler reports those as pages missing from the sitemap instead, which is the right call since page 2 onwards is canonical to itself and not in the sitemap).

What we'd fix first

1. Redirect the dead guide URL that still earns impressions, and link the Black Friday page from pricing. Both are ten-minute jobs with a visible result in Search Console.
2. Shorten the 20 over-length titles, starting with the five that have impressions (/seo-audit, the Sitebulb comparison, two blog posts and an issues page).
3. Bring the /issues/ai and /issues/security pages up from depth 6 with in-body links from /features and /issues.

Then re-crawl. The Audits page keeps both runs so the next one shows exactly which findings closed. Everything here, from the crawl settings to the Search Console views, is in the guide to connecting Search Console and the Search Performance guide.