What a link graph shows that a list of links cannot
A list of links is data you can query. A drawing of the same links is a shape you can recognise, and there are four things about a site that nobody notices in a table and nobody misses in a picture.
The short answer
The internal link graph is your site as a set of nodes and edges, and four things only become visible when you draw it: hubs concentrating far more links than intended, clusters that connect internally but not to each other, bottleneck pages every route passes through, and pockets reachable only by one fragile path.
Four things you only notice when you look at it
This check produces a view rather than a verdict, which makes it unusual in this audit. The justification for it is specific: these four patterns are all visible at a glance and effectively invisible in a sorted list.
- Isolated pockets. A group of pages that link densely to each other and are reached from the rest of the site by one link, or none. Every page in the pocket has a healthy inbound count, so nothing in a table looks wrong. On a drawing it is an island.
- Bottlenecks. A single page that every route into a section passes through. It looks like a well-connected hub in a count, and it is a single point of failure: if it is removed, renamed or accidentally set to
noindex, the section behind it loses its route. - Unintended hubs. The page your site links to most is frequently not a page anybody nominated. A tag archive, a legal notice, a login. Seeing your actual centre of gravity is uncomfortable and useful.
- Asymmetry. Sections that link out heavily and receive nothing, or the reverse. In a table these are two numbers on two separate rows. Drawn, they are a flow going one way.
What a graph is bad at is anything quantitative. You cannot read a count off it, you cannot sort it, and past a few thousand nodes it becomes a cloud that shows you density and nothing else. Use it to form a question and the table to answer it.
Three renderings, three jobs
The same edges drawn three ways answer different questions, and picking the wrong one is why people conclude that graph views are decorative.
- A tree, rooted at the home page. Shows depth and hierarchy, and it is the view that makes a buried section obvious. It hides the links that make a site a graph rather than a tree, so it is a simplification by design and the easiest to read.
- A force-directed graph. Nodes repel, edges pull, and clusters emerge without anyone defining them. The right view for finding pockets and unexpected groupings. Worth remembering that the positions carry no meaning beyond connectedness: a node on the left is not to the left of anything.
- A sortable table. Not a picture at all, and the only one that lets you act. Sort by inbound ascending and the top of the list is your work queue.
A fourth view worth asking for if you ever build this yourself: the same graph with your revenue or traffic figures as node size. A structure that looks balanced can be badly wrong once the important pages are marked, and that overlay turns an aesthetic judgement into a business one.
An edge needs both of its ends
A graph is made of edges, and an edge is a relationship between two pages. One page can tell you what it links to and nothing about what links to it, so there is no partial version of this view for a single URL.
This one needs the full crawl
A graph is made of edges, and an edge needs both ends. Nothing about one page can show you the shape it sits inside.
The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.
Does this affect AI search?
The graph itself, no. Nothing reads your site structure as a shape, and no retrieval system has a concept of your topology. What matters is the consequences the shape produces, which are covered by the checks a graph helps you find: pages nothing links to, sections behind a bottleneck, routes that dead-end.
There is one honest connection specific to the machine case. A pocket that is reachable through a single link is, for an agent that follows two or three links, effectively not part of your site. A search crawler will get in eventually. Something answering a question now will not, so the asymmetry the graph exposes maps directly onto what is available to be cited.
The most useful way to use this view for that purpose is to find your best answers on the drawing and see how far they are from the centre. If the material you would most want quoted sits in an island, that is a link problem rather than a content problem.
Why a view of your site cannot rate higher
Because it is not a finding. Everything a graph shows is reported as a defect by some other check, with a name and a fix attached: an orphan, a dead-end route, a page at depth eight. This is the lens rather than the diagnosis, which puts it at the bottom of the scale by construction.
It stays in the catalogue because the lens finds things no rule was written for. Nobody has a check called "the documentation is an island" or "every route into the shop runs through one page", and both are real structural problems that a person spots in five seconds on a drawing. Some findings are only available to a human looking at a picture, and that is a reasonable thing for a report to provide.
It is also the view that makes the rest of this pillar make sense. Depth, authority, orphans and relationships are all statements about the same graph, and reading them without ever seeing it is how teams end up fixing the numbers instead of the structure.
Building a crude edge list yourself
You can get a usable adjacency list out of a shell and read the interesting parts of it without any drawing at all.
curl -s https://example.com/sitemap.xml \
| grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' | sort -u > /tmp/pages.txt
# one line per edge: "source<tab>target"
while read -r page; do
from=$(printf '%s' "$page" | sed 's|https://example.com||')
curl -s "$page" \
| grep -o 'href="/[^"#?]*"' | sed 's/href="//;s/"$//' | sort -u \
| while read -r to; do printf '%s\t%s\n' "$from" "$to"; done
done < /tmp/pages.txt > /tmp/edges.tsv
# the pages your site links to most, which is your real centre
cut -f2 /tmp/edges.tsv | sort | uniq -c | sort -rn | head -15
# and the ones nothing links to
comm -23 \
<(sed 's|https://example.com||' /tmp/pages.txt | sort -u) \
<(cut -f2 /tmp/edges.tsv | sort -u)The second command is the one worth running today. The top of that list is what your site actually treats as important, and it is rarely what the strategy document says.
The edge list is also the input for a drawing if you want one: most graph tools accept two columns of identifiers, so the file above is enough to render the thing this check describes.
Questions this check raises
- What is a bottleneck page?
- A page that sits on the only route to a group of others, so its removal or its noindex directive disconnects everything behind it. They are invisible in a sitemap and obvious in a graph, and they are usually a category index nobody thought of as load-bearing.
- Why does the link graph matter more than link count?
- Because a count is a property of one page and the graph is a property of the site. Two sites can have identical average link counts while one is a single connected structure and the other is four clusters that never reference each other, and only the second has pages that are hard to reach.
- Do navigation links count the same as body links?
- Not in practice. A link repeated in every header carries less weight than one placed in the body of a relevant page, because the first says nothing about this specific page and the second is an editorial judgement. A graph built only from navigation shows a site that is uniformly connected and tells you nothing.