Home › SEO Guide › What a site Google can read looks like
What a site Google can read looks like
The central idea of this chapter fits in one sentence: what you see on the site is not necessarily what Google receives. And when the two differ, the difference shows up nowhere. The site looks fine, nobody complains, and the pages do not rank.
Why they can differ
Your browser does much more than display a file. It runs code, requests additional data, builds pieces of the page after you have landed on it. A search robot receives the raw text first and only then, maybe, runs the code.
On top of that, many sites deliberately serve different responses: one version for logged-in visitors, another for anonymous ones, another from the cache, another for robots. Each of these variants can be broken separately, without the others giving any sign.
Case one: an entire site without internal links
On two insurance sites, built on the same platform, we discovered that every internal link in the version served to robots pointed to the homepage.
An article card looked like this in the code Googlebot received:
<h2 class="titlu"><a href="/">How to choose the right RCA policy</a></h2>
The right title, the wrong address. One of the sites had 18 published articles and none of them reachable by following a link. The homepage had a total of four distinct internal URLs, three of them pointing to legal pages.
The cause: the site builds its URLs with a function that needs the list of routes. That list was available only in the browser. For server-side rendering, someone had put in a stand-in that returned the homepage for any address requested, so that rendering would not stop with an error. It did not stop. It silently produced a site without structure.
Visitors saw nothing unusual. The code ran in the browser, the links corrected themselves instantly, everyone browsed normally.
Only Google and the AI assistants that do not run code received the broken variant. That is, exactly the ones for whom internal links matter.
After the fix, the homepage went from 4 to 22 internal URLs, and the articles became reachable. A useful side effect: the contact page got linked on its own, because the menu used the same faulty function.
Case two: a checkbox that empties the links
On four sites, the author box below the articles contained a link with no destination:
<a href="" rel="author">Author name</a>
The cause was a single option ticked in a very widespread plugin, which disables author pages. The plugin disabled the pages, but the template kept generating the link to them. The result: an empty link on every article.
A visitor who clicks on it stays where they are and thinks the page has frozen. A robot sees a byline that leads nowhere, so an author it cannot verify.
A second case from the same family, and more instructive because the mistake is ours. On two sites we had written a security rule that blocked access to a certain type of URL, to limit a method of automatically harvesting usernames. The rule was right in intent and too broad in wording: it also blocked the legitimate author pages, which ended up redirected to the homepage.
So we had, at the same time, an author box that pointed somewhere and a rule of our own that made that somewhere not exist. Both written with good intentions, both invisible without checking.
What “readable” means in practice
| Element | What it is for |
|---|---|
| Internal links | They are the roads by which your pages are reached. A page no link leads to is a page that almost does not exist |
| Page title and description | They are what gets read in the results, before entering. Each page needs its own, different ones |
| A single main heading | It says what the page is about. Subheadings organize the rest, in order |
| Structured data | It translates into machine language what the page is: article, product, company, author. It does not raise rankings on its own, but it makes the information indisputable |
| Text for images | The alt description. A robot does not see the photo, and a person using a screen reader even less |
How to check for yourself, without tools
Three methods, in order of effort.
Searching your own site
Type into Google site:your-domain.ro. You get the approximate list of known pages. If the number is much smaller than what you actually have, you have an access problem, not a content problem.
Viewing the source code
On any page, right-click and choose to view the page source. The raw text opens, roughly what a robot receives before running code. Search in it, with the browser's find function, for a fragment of the page's main text. If you do not find it there, the content is built afterwards, and that is worth discussing.
The inspection tool in Search Console
The best of the three, because it shows you exactly what Google saw. Paste a page's URL into the bar at the top and you will find out whether it is indexed, when it was last visited and what problems it ran into.
The rule that sums up the whole chapter: none of the problems above can be seen by browsing the site normally.
A site can look perfect and be, at the same time, unreadable to the engine that is supposed to bring you customers. That is why checking is not optional, and “it looks fine in my browser” is not an argument.
What to check
- Search for
site:your-domain.roand compare the number of results with the real number of pages. - Open the source of the homepage and search in it for a sentence from the visible text.
- On an article, click the author's name and one of the menu links. Do they actually lead somewhere?
- Open Search Console and read the indexing report: how many pages are indexed and how many are not, with the reason.
- If the site is built on a platform that renders in the browser, explicitly ask to be shown what a robot receives. It is a ten-minute check.