← Back to Blog

Footer Completeness: Why Every Sitemap URL Needs At Least One Footer Link

Footer Completeness: Why Every Sitemap URL Needs At Least One Footer Link

I run a tool called the Link Graph + Sitemap Delta. It does one thing: compares every URL in your sitemap to every internal anchor on your site and tells you which URLs appear in one but not the other. Last week I ran it against four of my own sites. Each one came back with the same flag: /glossary/ listed as "sitemap-only."

The glossary page was real. It rendered fine. The sitemap included it correctly. The only problem was that no internal link anywhere on the site pointed to it. Nav didn't link to it. Footer didn't link to it. No blog post mentioned it. Which meant it was, by every practical measure, invisible — even though the sitemap said "here, look at this."

What an Orphan Actually Is

An orphan in SEO terms is a page with zero inbound internal links. Sitemaps don't count as inbound links. A sitemap is a discovery mechanism, not a signal of importance. Google and Bing will find the page, crawl it, maybe index it, but they will not flow authority to it because there's no link graph edge telling them the site considers this page important.

Search engines are explicit about this. In any discussion of site architecture, the guidance is the same: every page that matters should be reachable from the homepage within a few clicks. Sitemap inclusion is necessary but not sufficient. If the only way a crawler can reach /glossary/ is by reading the sitemap, the glossary effectively sits outside your site's authority graph.

The Simplest Fix: Footer Quick Links

The footer is the cheapest place to solve this. Every page on the site renders the footer. Every URL that needs to be reachable can get an inbound link for free just by being listed in a "Quick Links" block.

The template I use across every site I run:

<footer>
  <nav aria-label="Quick links">
    <h3>Quick Links</h3>
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about/">About</a></li>
      <li><a href="/contact/">Contact</a></li>
      <li><a href="/faq/">FAQ</a></li>
      <li><a href="/glossary/">Glossary</a></li>
      <li><a href="/stories/">Stories</a></li>
      <li><a href="/tools/">Tools</a></li>
      <li><a href="/privacy/">Privacy</a></li>
      <li><a href="/cookies/">Cookies</a></li>
      <li><a href="/accessibility/">Accessibility</a></li>
      <li><a href="/disclaimer/">Disclaimer</a></li>
    </ul>
  </nav>
</footer>

That's eleven links. On a typical site I run, that's 90% of the URLs that would otherwise be at risk of sitemap-only status. Blog posts and tool pages usually have inbound links from collection pages (/blog/, /tools/), so they're safe. The high-risk URLs are the secondary pages: glossary, stories, cookies, accessibility, disclaimer. Without a footer, they're invisible.

The Detection Logic

The Link Graph tool runs this logic on every crawl:

for each url in sitemap.xml:
  inbound_count = count(internal_anchors where href = url)
  if inbound_count == 0:
    flag(url, "sitemap-only orphan")

for each url in crawled_anchors:
  if url not in sitemap.xml:
    flag(url, "crawl-only, possibly 404")

Pseudocode, but it's exactly what the tool does. The sitemap is the source of truth for "pages that should exist." The anchor crawl is the source of truth for "pages the site actually links to." The difference between the two sets is where bugs live.

I wrote it after getting tired of manually eyeballing sitemap versus nav on every site audit. The set difference is a one-line operation in SQL or any reasonable scripting language. Making it a tool just means I run it on every deploy instead of every quarter.

Why the Footer Matters More Than Nav

The main nav usually has five to seven links. If you put all eleven Quick Links in the main nav, it becomes a mess. The footer is where secondary navigation belongs, and it's where users expect to find Privacy, Terms, Accessibility, and the rest of the boilerplate. Adding Glossary and Stories to the same list is a small stretch that costs nothing.

There's a second reason. Footers render on every page, including on each blog post and tool page. That means each footer Quick Link is effectively getting N inbound links, where N is the total page count of your site. A 200-page site with a Glossary link in the footer gives /glossary/ 199 internal inbound links. That is a meaningful authority signal compared to the zero it had before.

Common Mistakes

"I'll add it to the sitemap and Google will handle it." No. Sitemap inclusion signals existence, not importance. The page will get crawled and probably indexed, but it won't rank for anything meaningful because no part of your own site is willing to link to it. That signal is louder than the sitemap.

"I have it in the nav on mobile only." Easy mistake. If your mobile nav has a Glossary link but the desktop nav and footer don't, then desktop rendering (which is what most crawlers default to) sees no inbound link. The Link Graph tool renders with a standard desktop user agent and will flag it as orphan.

"I link to it from one blog post from 2023." Depends on the blog post. If the post is in your collection index and has its own inbound links, you're probably fine — the Glossary is two clicks from the homepage. If the post is itself an orphan (a draft, an unpublished one, or a 404), then your Glossary inherits the orphan status.

A Concrete Example from This Week

On one of the property sites I run, the Link Graph tool flagged three URLs as sitemap-only:

- /glossary/
- /disclaimer/
- /stories/

All three were real pages, rendering correctly, listed in the sitemap. None were linked from nav or footer. I added all three to the footer Quick Links block, committed the template change, deployed. Re-ran the Link Graph tool. Zero sitemap-only flags.

Total time: four minutes. The pages were already written, already styled, already sitemap-indexed. They just needed a single anchor tag each to become real parts of the site.

When to Prune Instead of Link

Sometimes the right answer is not "add a footer link" but "remove from sitemap." If you have a page in your sitemap that you genuinely do not want users to see, it should not be in the sitemap. Tag archives from an old CMS, draft pages left in by accident, legacy redirects — these belong out of the sitemap, not linked from the footer.

The Link Graph tool won't decide for you. It will surface the mismatch and let you pick: link to it or prune it. Both are valid. The wrong answer is to ignore the flag.

The Short Version

  • A page in your sitemap with zero inbound internal links is an orphan. Search engines will deprioritize it because authority has no path to flow.
  • The cheapest fix is a footer Quick Links block that includes Home, About, Contact, FAQ, Glossary, Stories, Tools, Privacy, Cookies, Accessibility, Disclaimer.
  • Every sitemap URL should have at least one footer inbound. Blog posts and tool pages get inbound links from collection indexes; secondary pages need the footer.
  • Run /tools/link-graph/ to find sitemap-only orphans and crawl-only 404s on your site.
  • When a flagged URL is one you don't want to surface, prune it from the sitemap instead of adding it to the footer. Either fix is valid; ignoring it is not.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026