How do you audit internal links on a 500 page CMS site?

How do I audit internal links when I have hundreds of CMS posts?

Crawl the site, export what links to what, then compare that against your full page list to find what nothing points at. On a site of roughly 500 pages you can do all of it with a free crawler and Google Search Console in an afternoon, without buying anything.

This is written for one specific situation: you own a content site built on a CMS, it has grown past the point where you can remember what links to what, and nobody has given you a tooling budget. That describes most marketing teams I work with.

I am going to give you the actual sequence rather than the theory, because internal linking is one of those jobs where people understand the principle perfectly and still never do it.

What are you actually looking for?

Three things. Pages nothing links to, pages that soak up every link for no reason, and pages that should link to each other and do not. Everything else in an internal link audit is detail hanging off those three findings.

Orphans are the expensive one. A page with no internal links is reachable only from a sitemap or an external link, which means it is competing with one hand tied behind its back. On a CMS site these appear constantly, usually because a post was published, shared once, and never referenced again.

The opposite problem is quieter. One page, usually the homepage or a pillar article, ends up linked from everywhere, while the pages that actually answer specific buyer questions get nothing. That is a distribution problem, not a volume problem, and adding more links without fixing it just makes it worse.

Which tools do you need, and what do they cost?

A desktop crawler and Search Console. Screaming Frog states on its own site that the free version is restricted to crawling up to 500 URLs in a single crawl, which is exactly the size of site this article is about, so for many people the cost is zero.

Screaming Frog is also clear about what the free version gives up. Its site says crawl configuration, saving of crawls, and advanced features such as JavaScript rendering, custom extraction and API integrations are restricted. Two of those matter here. You cannot save the crawl, so finish the job in one sitting, and JavaScript rendering is off, which matters if your links are injected by script rather than present in the HTML.

If you outgrow the free tier, Screaming Frog's site states a licence at £199 per year that removes the 500 URL limit, allows saving crawls and opens up configuration and advanced features. Check the current price on their site before you budget, because pricing changes and I am quoting what the page says today.

Search Console is free and gives you something the crawler cannot: what Google itself thinks your internal link structure looks like. You want both views, because they disagree in interesting ways.

How do you get the full list of pages first?

Start from your sitemap, usually published at slash sitemap dot xml, and turn it into a flat list of URLs in a spreadsheet. That list is your denominator. Without it you can find badly linked pages but you cannot find missing ones.

Pull the sitemap in a browser, save the XML, and extract the location values into a single column. If your sitemap is split into an index pointing at several child sitemaps, grab each child and stack them. It is five minutes of unglamorous work and every later step depends on it.

Sort that list and read it. This step alone usually surfaces something surprising, like a template page you forgot existed or a set of test posts that were never unpublished. Fix those before you audit anything, because auditing links to a page that should not exist is wasted effort.

How do you crawl the site without paying for anything?

Point the crawler at your homepage, let it run to completion, then export the inlinks report. That export is a row per link, with the source URL and the destination URL, which is the raw material for everything that follows.

Two settings matter before you start. Restrict the crawl to your own domain so you are not counting outbound links, and make sure you are crawling the live domain rather than a staging URL, because staging sites often have different navigation. If your site relies on JavaScript to render links, remember the free tier does not render it, so verify a couple of pages by hand.

When it finishes, export the list of crawled URLs as well as the inlinks. You now have two lists: what the crawler could reach, and what your sitemap says exists. The difference between them is the most useful output of the whole exercise.

How do you find orphan pages?

Compare the sitemap list against the crawler's list of URLs with at least one inbound internal link. Anything in the sitemap that the crawler never reached through a link is an orphan, and those are your priority fixes.

In a spreadsheet this is one lookup. Put the sitemap URLs in one column, the set of link destinations in another, and flag every sitemap URL that does not appear as a destination anywhere. On a site of a few hundred posts this takes minutes and usually returns more rows than people expect.

Then read the orphan list and be honest about each one. Some orphans deserve links. Some are genuinely finished business and should be consolidated or removed. An audit that only ever adds links will bloat the site, which brings its own problems as an archive grows, something I have written about in what changes when your blog passes a thousand pages.

What does Search Console tell you that a crawler cannot?

It tells you what Google sees. Google's documentation describes a Links report with a top internally-linked pages table showing which of your pages is linked the most from within your own site, and says you can select a URL in the list to see which of your other pages link to it.

Google also documents a path for the reverse question, going from the Links report through Internal links and Top linked pages to see which pages link to a given page. That is the view to use when you are checking whether a specific important page is getting any internal support at all.

Export limits matter for how you use this. Google's documentation says you can export up to 100,000 rows of link data, and that pages containing a single table offer a download button that exports the entire table up to 1,000 rows, as a CSV file or a Google Sheet. For a 500 page site that is comfortable, and it means you can diff Google's view against your crawler's view directly in a spreadsheet.

Where they disagree is where the learning is. A page your crawler reaches easily but Google shows as barely linked usually means the links sit in a template region that carries less weight, or in markup Google is discounting.

How do you decide which links to add?

Add links where a reader would genuinely want one, from pages that already get traffic, using the words a reader would search. If you cannot write the sentence naturally, the link does not belong there.

The highest value move is to link from your best performing pages down to your orphans, not the other way round. A link from a page nobody reads is an administrative act. A link from a page with real traffic is distribution.

Keep the anchor text descriptive and varied. One canonical phrase per concept across the site helps both readers and machines understand what a page is about, and it is far more useful than stuffing an exact phrase into every anchor.

Resist the urge to add a related posts block instead. Automated blocks are easy and almost worthless, because they are not about the sentence the reader just read. Links woven into prose are the ones that get clicked.

How often should you repeat this?

Quarterly for a site publishing regularly, or whenever you add a batch of content large enough that you cannot remember all of it. The crawl is cheap once you have the process written down.

What I actually recommend is a small habit instead of a big audit. Every time you publish, link the new piece from two existing pages. Do that consistently and the quarterly audit becomes a formality rather than a rescue mission.

The reason to keep auditing at all is that structure decays. Posts get unpublished, slugs change, navigation gets redesigned, and each of those quietly creates orphans. It is also worth thinking about how deep pages sit in the structure, which I have covered in pagination and crawl depth on a large blog.

What should you do next?

Block out two hours this week. Pull your sitemap into a spreadsheet, run a free crawl, export the inlinks, and produce one list of orphan pages. Do not fix anything yet. Just get the list.

Then pick the ten orphans that matter most commercially and add one good in prose link to each from a page that already gets traffic. That is a genuinely finishable piece of work with a visible result, which is more than most SEO tasks can claim. If your site is much larger than this, the priorities shift, and I have written about that in what actually matters for crawl budget on a large CMS site.

If you get the list and cannot tell which orphans are worth rescuing, reach out. That judgement call is the part worth a second opinion, and the crawling is the easy bit.