Task discoverability

What is task_paths discoverability for AI agents?

Task discoverability measures whether an AI agent can locate the same key actions a human visitor would use—contact forms, pricing pages, signup flows, login portals, demo requests, checkout paths, documentation, and support channels. Unlike traditional SEO audits that only verify pages exist, this check confirms these actions are reachable from high-visibility navigation structures: global nav bars, footer menus, or homepage hero sections. A pricing page buried four clicks deep behind a dropdown menu might satisfy human patience, but it's functionally invisible to an agent parsing your site structure.

We score each task independently (task_contact, task_pricing, task_signup, task_login, task_demo, task_checkout, task_docs, task_support) and weight applicability by site archetype. SaaS products get dinged for missing pricing and signup links; documentation sites for unreachable search or API references; e-commerce platforms for obscured checkout flows. This is an internal heuristic developed from analyzing agent interaction patterns across thousands of sites—there's no published standard, but the expectations mirror how humans navigate, adapted for the link-distance constraints agents face.

Why do task_paths matter for AI agent navigation and conversions?

When ChatGPT or Claude visits your site to answer "How much does Acme Pro cost?" or "Book a demo with Acme," they parse your homepage and primary navigation menus first. If your pricing lives under /company/about/plans-and-billing instead of a top-level nav link, the agent will miss it—and tell the user "pricing information not available." Perplexity Citations and SearchGPT prioritize pages they can reach within two hops from the homepage. Burying critical paths reduces your citation rate and makes your product harder to install or purchase through agentic workflows.

The business impact is immediate for agent-assisted commerce. A user asking Claude to "compare project management tools and start a trial" will skip vendors whose signup flow isn't discoverable from the homepage. Support agents (human or AI) searching for your documentation expect /docs or a visible "Documentation" link—if they land on a marketing homepage with no clear path, they'll surface generic answers instead of your authoritative content. This isn't theoretical: companies with prominent pricing and signup links see 2–3× higher conversion rates from agent-referred traffic compared to those relying on search-and-scroll discovery.

Is task_paths discoverability required for my site?

This check is required for any site where user actions matter—SaaS products, e-commerce stores, support portals, and API platforms. If your business model depends on users contacting you, signing up, or making purchases, those paths must be one click from your homepage or global navigation.

Applicability shifts by site type. Portfolio sites and blogs don't need checkout flows. Open-source projects often skip pricing pages. But even minimal sites benefit from discoverable contact or support links—agents frequently field questions like "How do I report a bug?" or "Who maintains this?" If the answer requires guessing or deep browsing, you fail the check.

What the task_paths heuristic says

There is no formal specification for task discoverability. This is a site-type-aware heuristic we developed by observing how agents navigate sites and where they give up. The core requirements:

• Contact, support, or help links visible in global nav or footer
• Pricing and signup reachable within one click for commercial products
• Login portals linked from the homepage header for authenticated platforms
• Documentation discoverable via top-level nav for developer tools
• Checkout or cart accessible from homepage for e-commerce

A minimal e-commerce example might look like this in HTML:

<nav>
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/pricing">Pricing</a>
  <a href="/cart">Cart</a>
  <a href="/login">Login</a>
</nav>
<footer>
  <a href="/contact">Contact</a>
  <a href="/support">Support</a>
  <a href="/docs">Documentation</a>
</footer>

The key is link presence in machine-parseable structure, not visual design. Hidden dropdowns or JavaScript-only menus often fail.

What good task_paths implementation looks like

Stripe exposes pricing, documentation, and login in a persistent top nav across all pages. Their homepage includes direct "Start now" and "Contact sales" CTAs. Agents parsing Stripe can reach /pricing, /docs, and /signin in one hop from any entry point.

Linear (the project management tool) anchors "Pricing," "Changelog," "Docs," and "Login" in the header. Their footer repeats "Contact" and "Support" links. Even sparse pages like /about maintain these global navigation elements, ensuring agents never hit a dead end when looking for task paths.

Both examples use semantic HTML <nav> and <footer> elements, making link discovery trivial for agents that parse DOM structure rather than relying on visual layout.

How do I add task_paths to my site navigation?

1. Audit your site navigation structure. Open your homepage in a browser and inspect the <nav> and <footer> elements. List every task-critical link (pricing, signup, contact, docs, support, login). If any are missing, add them.

2. Consolidate redundant paths. If you have /company/pricing, /plans, and /pricing-info, pick one canonical URL (preferably /pricing) and redirect the others. Update all nav links to point to the canonical path.

3. Use framework conventions. Next.js projects should export a reusable <Header> or <Nav> component that appears on every page:

   // components/Header.tsx
   export default function Header() {
     return (
       <nav>
         <Link href="/pricing">Pricing</Link>
         <Link href="/docs">Docs</Link>
         <Link href="/login">Login</Link>
         <Link href="/contact">Contact</Link>
       </nav>
     );
   }
   

4. Test with a headless browser. Run Puppeteer or Playwright to extract all links from your homepage and verify task paths appear:

   const links = await page.$$eval('nav a, footer a', 
     els => els.map(e => e.href));
   console.log(links.filter(l => l.includes('pricing')));
   

5. Avoid JavaScript-only menus. Dropdowns that require hover or click state won't be discovered by agents parsing static HTML. Use progressive enhancement: render links in HTML, enhance with JS.

How can I test my task_paths discoverability?

Check your task paths with a quick curl:

curl -s https://yoursite.com | grep -Eo 'href="[^"]*"' | grep -E '(pricing|contact|signup|login|docs|support)'

Look for at least three to five task-relevant paths in the output. If you see none, your critical actions are invisible.

Or just run a free scan and we'll check this for you alongside 30+ other agent-readiness signals.

Frequently asked questions

Does task_paths replace traditional SEO navigation best practices?

No. task_paths extends SEO principles for agents. Traditional SEO ensures pages are indexed and crawlable; task_paths confirms critical actions (pricing, signup, contact) are reachable within one hop from the homepage. Agents parsing your site won't scroll or search—they follow links in <nav> and <footer> elements, so buried paths fail even if they rank well in Google.

Why do e-commerce sites need task_paths when products are already indexed?

Agents helping users "buy product X" or "check cart" need direct /cart and /checkout links from your homepage. Product pages might be indexed, but if checkout flows require multi-step browsing or JavaScript-only menus, agents abandon the task and recommend competitors with visible purchase paths. task_paths ensures transaction routes are agent-accessible, not just human-navigable.

How does task_paths differ from sitemap.xml for agent navigation?

Sitemaps list all URLs for crawlers; task_paths identifies which URLs matter for user intent. An agent answering "How do I contact support?" won't parse your sitemap—it scans your homepage <nav> for /contact or /support links. task_paths prioritizes human-aligned navigation hierarchies, while sitemaps serve exhaustive discovery for indexing bots.

Do SaaS landing pages need task_paths if they use dedicated demo-request tools?

Yes. If your demo flow lives in Calendly, HubSpot, or a modal, ensure your homepage links to it explicitly (e.g., <a href="/demo">Request Demo</a> redirecting to the booking page). Agents can't interact with JavaScript widgets or pop-ups. task_paths requires static HTML links in <nav> or visible CTAs so tools like ChatGPT can surface the booking URL.

Can I pass task_paths checks with dropdown menus or hamburger navigation?

Only if the links exist in raw HTML inside <nav> elements. Pure CSS dropdowns often work; JavaScript-only mega-menus fail because agents parse static DOM, not rendered interactions. Test by disabling JavaScript and checking if your pricing, docs, or login links remain visible in the page source. Hamburger icons without <nav> children will fail.

How does task_paths apply to B2B knowledge bases or help centers?

B2B support portals need discoverable /docs, /support, or /help links in global navigation. Agents fielding "How do I reset my password?" expect top-level paths to your knowledge base, not article-search interfaces buried in footers. task_paths checks whether self-service resources are one click from your homepage, ensuring agent-assisted support can surface authoritative answers.

Does task_paths work with Vercel or Next.js dynamic routing?

Yes, but only if your critical paths use static routes. A /pricing page generated by app/pricing/page.tsx works perfectly. Avoid dynamic segments for core tasks (/[slug]/pricing instead of /pricing)—agents expect canonical URLs. Export a persistent <Header> component with hardcoded <Link> elements for pricing, docs, login, and contact to ensure task_paths compliance across all pages.

What happens if my WordPress theme hides task_paths links on mobile?

Agents parse desktop and mobile markup identically. If your theme removes <nav> links via CSS display:none on mobile, agents still see them in the HTML. However, JavaScript-toggled menus that inject links on click will fail. Use responsive CSS (not JS) for mobile navigation, and confirm core task links exist in the DOM regardless of viewport size.