The Tools Nav Trap: When Your Dropdown Promises a Page That Doesn't Exist

I audited five sites this week. Four of them had the same quiet bug: a "Tools" dropdown in the main nav, each child link pointing to a real working tool page, and zero landing page at /tools/. Click the dropdown label itself and you get Netlify's 404 fallback. Click any child, you get a working tool. The label is a lie.

The HTML usually looks like this:

<li class="dropdown">
  <button type="button" aria-expanded="false">Tools</button>
  <ul class="dropdown-menu">
    <li><a href="/tools/mega-analyzer/">Mega Analyzer</a></li>
    <li><a href="/tools/analyzer/">Site Analyzer</a></li>
  </ul>
</li>

The parent is a <button> with no href. That's fine for accessibility, and it's the correct pattern for a dropdown toggle. The bug is everything else around it. Users hover the label, then try to tab or click through, then sometimes end up at /tools/ directly because they saw the URL pattern in the children and guessed the parent. Crawlers do the same thing — link-graph inference will assume a parent exists for any child under /tools/....

Where the Signal Breaks

A dropdown labeled "Tools" sets an expectation. Three kinds of visitors arrive at /tools/:

1. Humans who saw the label, typed the URL directly, or followed an outside reference that assumed a hub exists.
2. AI retrieval engines that crawl your site and normalize the link graph. They see /tools/foo/ and /tools/bar/ and back-fill /tools/ as the parent node.
3. Sitemap diff tools (including mine) that flag the parent as "implied by children, missing from sitemap and served as 404."

All three hit the Netlify catch-all and get a 404. On a site with any authority, that 404 shows up in Search Console within a week. On a site with an llms.txt that mentions tools in the section list, AI engines have a stronger-than-usual reason to probe /tools/ and find nothing.

How the Catch-All Hides It

Most Netlify configs end with something like:

[[redirects]]
  from = "/*"
  to = "/404/"
  status = 404

If you're testing in production, you never see /tools/ fail as anything other than your branded 404 page. The dropdown still opens, the children still work, the site still feels healthy. The only way to notice is to either audit the link graph directly or watch your server logs for 404s on URLs that look like nav parents.

That's exactly the check /tools/link-graph/ runs. It compares your sitemap to every internal anchor on the site and flags three categories:

• Sitemap-only — URL is in your sitemap but no internal nav or footer link points to it (orphan).
• Crawl-only — URL is linked from the site but not in your sitemap (often 404).
• Nav-implied — parent path inferred from child links, no page exists at the parent.

Nav-implied is the category the Tools dropdown falls into. The Link Graph tool flagged four sites in one run last Tuesday.

The Fix: Ship a Real Hub Page

A tools hub does not need to be elaborate. It needs to exist at /tools/, list the tools on this site, and cross-link to the full suite on the tools hub domain. Here's the minimum viable version in Eleventy:

---
layout: page.njk
permalink: /tools/
title: "Tools"
pageTitle: "Free SEO and AEO Tools"
pageDescription: "The tools I ship on this site, plus cross-links to the full free suite on jwatte.com."
---

<h1>Tools</h1>

<p>Two small tools live on this site. The full suite (20+ tools,
covering link graph, schema completeness, voice cleanup, slug
renames, and more) lives on the main tools hub.</p>

<h2>On this site</h2>
<ul>
  <li><a href="/tools/mega-analyzer/">Mega Analyzer</a> — full audit, all signals.</li>
  <li><a href="/tools/analyzer/">Site Analyzer</a> — quick pass, essential checks.</li>
</ul>

<h2>On the main hub (jwatte.com)</h2>
<ul>
  <li><a href="https://jwatte.com/tools/link-graph/">Link Graph + Sitemap Delta</a></li>
  <li><a href="https://jwatte.com/tools/internal-link-auditor/">Internal Link Auditor</a></li>
  <li><a href="https://jwatte.com/tools/schema-completeness/">Schema Completeness</a></li>
  <li><a href="https://jwatte.com/tools/voice-cleanup/">Voice Cleanup</a></li>
  <li><a href="https://jwatte.com/tools/slug-rename-helper/">Slug Rename Helper</a></li>
</ul>

That's a hub. It exists, it orients the visitor, it turns the nav label into a truthful signal. The dropdown children still work; the dropdown parent now points somewhere.

Make the dropdown parent clickable too. Change the <button> to an <a href="/tools/"> with the dropdown triggered on hover, or keep the button for accessibility and add a "View all tools" link inside the dropdown that points to /tools/. Either is fine. The key is that /tools/ must resolve.

Netlify Redirect Gotchas While You're At It

Two things trip people up when they wire up a /tools/ hub:

1. Trailing-slash normalization. If you use [build.processing] pretty_urls = true in netlify.toml, Netlify will redirect /tools to /tools/ automatically. If you don't, you need an explicit rule:

[[redirects]]
  from = "/tools"
  to = "/tools/"
  status = 301

Do not add force = true to this rule. See the separate post on redirect loops; trailing-slash rules with force set will redirect to themselves on Netlify.

2. Rule order. Redirect rules in netlify.toml are evaluated top to bottom. If you have a catch-all /* near the top of the file, it will swallow your tool child routes before Netlify ever sees them. Put specific rules first, catch-all last.

# Specific rules first
[[redirects]]
  from = "/tools"
  to = "/tools/"
  status = 301

# Catch-all LAST
[[redirects]]
  from = "/*"
  to = "/404/"
  status = 404

I have caught the ordering bug on two separate sites where the catch-all shadowed every redirect beneath it. The symptom is "my redirects don't work" and the fix is "move them above the catch-all."

Why This Keeps Happening

The Tools dropdown is the single most common nav pattern I see on indie SEO sites. The reason the landing page gets skipped is almost always the same: the site owner added the dropdown as an organization device, not as a section. They thought of "Tools" as a category of pages, not as a place on the site. Categories don't need landing pages. Places do.

Once you think of /tools/ as a place — somewhere a visitor can arrive, orient themselves, and choose their next move — the fix is obvious. The Link Graph tool will confirm it.

The Short Version

• A "Tools" dropdown without a /tools/ landing page is a broken signal. Users, crawlers, and AI engines all expect the parent to exist.
• The dropdown <button> with no href is fine; the missing landing page is the bug.
• Netlify's catch-all hides the 404 behind a branded error page. Server logs and link-graph audits are where you see it.
• Ship a minimum viable hub: title, one paragraph, tools on this site, cross-links to the main hub.
• Put specific redirects before the catch-all in netlify.toml. Never add force = true to a slash-normalizing rule.
• Run /tools/link-graph/ against your site to find the "nav-implied" orphans automatically.