The problems that turned up most were not the technical ones a crawler reports. They were a broken link on a page buyers use, a claim with nothing behind it, and text left behind by a template. A crawler would catch fewer than half of the nine problems below on its own. The rest need someone to read the page and click every button.
The short answer
Most of what we find sits in the gap between "the page works" and "the page says and does the right thing". A crawler will tell you a link returns 404. It will not tell you that the link was the upgrade button on the pricing page, or that a messaging link was missing its country code, or that an image description was written for a different page. Those are the findings that come up again and again.
How this was put together
This pools the findings from our site audits, paid and free. We are deliberately not publishing how many audits, which industries, where the businesses are or when the audits were done. Any two of those, next to the examples below, would be enough to work out who a site belongs to, and some of these problems may still be live.
So frequency is given in words. "Every audit" means every one we pooled. "Most" means more than half. "Some" means at least two. The audits were not identical in depth, so a problem not being counted does not mean a site was clean.
To give you numbers we can stand behind in full, we then ran every check on our own site. That section has the exact figures, including the things we found wrong with it.
The nine problems at a glance
| Problem | How often | Would a crawler catch it? | The fix in one line |
|---|---|---|---|
| Broken link on a page buyers use | Every audit | Sometimes | Walk the buying path on a phone and click everything |
| A claim the page cannot support | Every audit | No | Put the source, date or conditions next to the claim |
| Text left behind by a template | Most | Rarely | Export every title, description and alt text, sort, and read the duplicates |
| Schema present, but describing a vague page | Most | No | Fix the page the markup describes before adding more markup |
| The offer is unclear on the page meant to sell it | Most | No | One page per service, answering six buyer questions |
| Main content slow to appear on mobile | Every site we measured | Yes, in a lab test | Let the main content show without waiting for animation or scripts |
| Content only a click can reach | Some | Yes | A real link with a real URL to every page you want found |
| A URL that names something other than its page | Some | No | Rename only when worth it, then redirect one to one |
| A "not found" page that reports success | Some | Yes | Return a 404 or 410 status for things that do not exist |
Frequencies come from our own audit records. "Would a crawler catch it" is our judgement of what a standard site crawler reports without someone reading the results. It is a small, non-random set of sites, so treat it as what we keep seeing, not as how common these problems are on the web.
Each problem and its fix
1. A broken link on a page buyers use
What we saw: an upgrade button on a pricing page that went to a 404. A WhatsApp link without a country code. A banner that covered the login button on mobile. Service pages linking to a case studies page that did not exist. A "schedule a call" button that opened a form instead of a calendar.
The fix: on a phone, in a private window, start from your own search result and click every button on your pricing, service and contact pages. Check WhatsApp links are wa.me/ followed by the country code and number, digits only. Make every phone number and email tappable. Make each button's label match what it does. Then send yourself a real enquiry and confirm it arrives where someone reads it. The full walk-through is here.
2. A claim the page cannot support
What we saw: outcome percentages with no source. Pricing examples presented as if they were full project costs. A comparison with a competitor that described features the competitor had since changed. Sample work shown beside paid client work with nothing to tell them apart. "Number one" in page titles.
The fix: keep the number and add what makes it checkable. A source, a date, or the conditions it was measured under. Say whether an outcome was measured or is an example. Date every comparison and recheck it against the other product's own documentation. Label sample or speculative work as exactly that. Remove superlatives you cannot prove, because a buyer, or an AI answer quoting your page, will repeat them back to you.
3. Text left behind by a template
What we saw: an unrelated company's name in a page title and its social sharing title. Instructions from a theme left in published copy. One image description repeated on every page built from a template. A published description that was keyboard filler. Lorem ipsum in FAQ answers.
The fix: search the whole site for placeholder words, then export every title, description, main heading and alt text into one sheet and sort each column. Identical values on pages that should be different point to a template reading the wrong field. Fix the template, not the page, so every page built from it is corrected at once. More on finding these, including the false alarms.
4. Schema present, but describing a vague page
What we saw: most of the sites already had structured data, some had an llms.txt file too, and one had markup that was missing a required property. Adding markup was never the main gap.
The fix: make the page worth describing first. A clear page for each service, client work that a reader can check, and the same facts about who you are and where you work on every page and profile. Then make the markup match what is visible on the page, and validate it. The evidence on schema and AI citations points the same way.
5. The offer is unclear on the page meant to sell it
What we saw: services advertised on the homepage with no page of their own. Two pages answering the same question. A cheaper product sitting beside the main service without saying who each was for. Free and paid tiers that did not line up with what the markup said.
The fix: give each service one page, and make it answer six questions a buyer has: what is included, who it is for, how it works, what affects cost and time, what you receive, and what happens after you get in touch. Where two pages overlap, give each a distinct job or merge them, after checking which one has the links and the clicks.
6. Main content slow to appear on mobile
What we saw: every site we ran Lighthouse on took more than 7 seconds to show its largest content on mobile in at least one run. Google's guidance puts a good largest contentful paint at 2.5 seconds or less. One site scored close to perfect on desktop and below 60 on mobile in both runs. On another the slowest element was an animated heading. Two runs on the same page could differ by more than 20 points.
The fix: show the main heading and image immediately, and start any animation after they are visible. Mark the most important image as high priority and stop other images competing with it. Defer scripts that are not needed for the first screen. Then run the test several times, not once, and report the spread. Lab tests are not real-user data, and we never present them as proof that speed is costing rankings.
7. Content only a click can reach
What we saw: blog pagination that changed the list of articles without changing the URL. Articles listed in the sitemap that no page on the site linked to. Items reachable only through app buttons.
The fix: Google says it can only reliably follow a link that is an <a> element with an href, and that each page in a paginated series should have its own URL. So give paginated pages addresses like /blog/page/2/, use real links rather than buttons for navigation, and link every article you want found from at least one related page.
8. A URL that names something other than its page
What we saw: page addresses naming a different item from the one on the page, an address ending in an encoded space, and a typo in a service URL.
The fix: check the old URL's traffic and links before changing anything. If renaming is worth it, redirect each old address permanently to its exact new one, never to a general listing, and update the internal links so they skip the redirect. Our redirect rules are written up here.
9. A "not found" page that reports success
What we saw: items that no longer existed returned a 200 status, which means success, and then showed "not found" to the visitor.
The fix: Google calls this a soft 404 and recommends returning a 404 or 410 status for content that does not exist. Decide on the server whether the thing exists, and send the right status before the page is drawn. Keep a helpful message and a route back for the person.
The same checks on our own site
We ran every check above on getborvis.com on 3 October 2026, across the 38 pages of the site, not counting the four published with this article. Because it is our site, we can give the exact results.
| Check | Result | What we did |
|---|---|---|
| Internal links | 1,073 links, 63 distinct addresses, all resolve | Nothing needed |
| External links, checked by script | 49 distinct links. First pass: 42 fine, 6 refused with a 403, 1 returned 404. Second pass an hour later: 4 refused | Opened the 6 by hand: 5 load normally in a browser, 1 showed a bot challenge we did not get past |
| The 404 | A Google help page we cited as a source had been removed by Google | Replaced it with Google's current page on the same topic |
| Missing pages | Return a real 404 status | Nothing needed |
| Address variants | http:// and https://www redirect correctly. http://www returns an error | Fixed the same day by switching on Cloudflare's Always Use HTTPS. It now reaches the site in two redirects |
| Placeholder words | 19 matches on 5 pages | All intentional: prompt templates with words in brackets, and "placeholder" used as an ordinary word |
| Duplicate titles and descriptions | None | Nothing needed |
| Duplicate main headings | 1, shared by the three pages of the insights list | Left as it is, since each page has its own title and description |
| Buyer path | One contact form and one email link. No phone or WhatsApp links to break | Nothing needed |
| Mobile Lighthouse, homepage, five runs | Scores 92, 98, 97, 97 and 98. Largest content at 2.7, 2.1, 2.1, 2.2 and 1.9 seconds | Nothing needed, but see below |
Three things from this are worth more than the scores.
- The script's broken links were mostly not broken. Six of the seven failures were sites refusing automated requests, and two of those let the same script through an hour later. The one real failure was a source page that the publisher had quietly removed. A report that lists all seven as broken would send someone off to fix five working links.
- The placeholder search mostly found our own templates. We publish prompt templates with words like [service] in brackets, so every match was deliberate. On a site like ours the search is noisy, and each match still needs reading.
- The first speed run was the outlier. Same page, same machine, a few minutes apart. Only the first run crossed the 2.5 second line. If we had run it once and stopped, we would have reported a problem that the next four runs did not show.
Words we kept out of the reports
Some of the most useful editing in these audits was taking words out. Each of these was in a draft at some point and came out because the evidence did not support it.
- Penalty. Rising impressions with flat clicks has an ordinary explanation: pages ranking too low to be clicked. Nothing pointed to a penalty, so the report said so.
- Cannibalisation. Two pages targeting overlapping questions became "potential intent overlap", because we had not shown they were taking clicks from each other.
- Unindexable. Broken pagination and unlinked articles are real faults. They do not mean a site cannot be indexed, especially when the sitemap still lists those pages.
- Missing pages. A small sitemap next to a lot of visible content looked like missing pages. Without a full list of URLs, it was a question, not a finding.
- Guaranteed. Nothing about rankings or AI recommendations went into any report as a promise.
We made the opposite mistake too. Once we reported a problem that had already been fixed, because we checked an old copy instead of the live page. Every finding is now rechecked against the live site, and labelled with which version of the site it came from, before it is sent.
Limits
- The pooled audits are a small set of sites chosen by who we worked with. They show what we keep seeing, not how common anything is.
- The audits differed in depth. Paid ones had more access, so more chances to find things.
- For the free audits we do not know what was fixed afterwards. Everything is described as found, not as still present.
- We did not submit forms or make payments on any audited site, so whether enquiries were being lost is outside what we tested.
- Our own site is small, static and recently built, which flatters it. It is a control, not a typical site.
Google: make your links crawlable
Google: pagination and incremental page loading
Google: soft 404 errors
WhatsApp Help Center: how to use click to chat
web.dev: Largest Contentful Paint thresholds
Chrome for Developers: Lighthouse performance scoring and variability
Our own audit records, and a self-audit of getborvis.com on 3 October 2026 using Lighthouse 13.4.1 and our own scripts