Intercepting Routes are triggered by hash/query-only URL changes — is this intended?

[pedrobeneditodev]

Context

While working with App Router + Parallel Routes + Intercepting Routes, I ran into a behavior that seems unintuitive and difficult to work around in real-world apps.

Intercepting Routes appear to be re-evaluated on any URL change, including changes limited to:

hash (#section)

search params (?tab=1)

even when the pathname does not change.

This causes parallel route slots to activate unintentionally.

---

Example scenario

A route exists in two forms:

/menu → real page (SEO, direct access, indexable)

@overlay/(.)menu → intercepting route used to render an overlay/modal

This is a recommended pattern to support:

SEO-safe routes

enhanced UX with overlays

However:

1. User accesses /menu directly (full page)

2. Inside /menu, clicks an anchor link (#section) or a link that only updates search params

3. The router treats this as a navigation

4. The intercepting route (.)menu is matched

5. The overlay slot becomes active

6. Result: duplicated UI (page + overlay)

No pathname change occurred, yet interception was triggered.

---

Why this feels problematic

From a developer and UX perspective:

Hash navigation is traditionally a DOM concern, not a routing concern

Anchor links inside a page should not activate overlays

This makes it unsafe to combine:

real pages

intercepting routes

internal anchors or query-based UI state

It forces developers to either:

avoid hash/query navigation entirely

or implement workarounds (sessionStorage flags, custom click handlers, router guards)

None of which feel aligned with the mental model of Intercepting Routes.

---

Expected behavior (question)

Is the current behavior intentional?

Intuitively, intercept matching would be expected to occur only when:

the pathname changes

or when navigation explicitly targets an intercepted route

Hash-only or search-only updates would ideally not trigger intercept evaluation.

---

Minimal structure

app/
├─ menu/
│ └─ page.tsx
├─ @overlay/
│ ├─ default.tsx
│ └─ (.)menu/
│ └─ page.tsx

Steps to reproduce:

1. Open /menu directly

2. Trigger a hash (#section) or search param change

3. Observe the overlay slot activating

---

Open questions

Is this behavior by design?

Are Intercepting Routes expected to react to hash/search changes?

Is there a recommended way to:

distinguish intentional intercept navigation

from in-page URL updates?

Would limiting intercept matching to pathname changes be feasible?

---

Closing

This isn’t a complaint — just trying to understand the intended mental model.

Right now, combining:

SEO-safe routes

intercepting overlays

and anchor navigation

feels fragile, and it’s unclear whether this is a known limitation or an area that might evolve.

Any clarification or guidance would be greatly appreciated.

[Toygarmetu]

This is a known quirk of how Next.js App Router handles intercepting routes. The interception matching checks the full URL (including search params) against the intercepting route pattern, and any navigation (including #hash or ?query changes) can re-trigger interception if the URL still matches.

Workaround: Detect whether navigation is an interception or an in-page update

Use usePathname() to track whether the pathname actually changed:

'use client';
import { usePathname, useSearchParams } from 'next/navigation';
import { useEffect, useRef } from 'react';

export function useIsInterceptedNavigation() {
  const pathname = usePathname();
  const prevPathname = useRef(pathname);

  useEffect(() => {
    prevPathname.current = pathname;
  }, [pathname]);

  return prevPathname.current !== pathname;
}

Then in your intercepting route's page.tsx, only render the modal if the pathname actually changed:

export default function InterceptedPage() {
  const isIntercepted = useIsInterceptedNavigation();
  if (!isIntercepted) return null; // Skip for hash/query-only changes
  return <Modal />;
}

Alternative: Use router.replace() instead of anchor links for in-page state changes, and check shallow routing patterns.

This behavior is arguably a bug — interception should ideally only trigger on pathname segment changes, not query/hash mutations. Worth opening an issue on the Next.js repo if you haven't already.

[sefin23]

To answer your core question: yes, this is the current behavior by design, but it's widely considered a rough edge of the Intercepting Routes implementation. Here's a clearer mental model and the most practical workarounds:

Why it happens

Next.js App Router's Intercepting Routes matching runs on every navigation event — the router doesn't distinguish between "pathname changed" and "only hash/search changed". Every call to router.push(), router.replace(), or a <Link> click triggers full route matching including intercepting route evaluation.

The interception condition ((.)menu matching /menu) is true regardless of whether #section or ?tab=1 was added — because the intercepting matcher only checks the pathname segment, and the pathname hasn't changed from the router's perspective of "did we navigate to this route?"

Workaround 1: Suppress hash/anchor navigation through the router

Instead of <a href="#section">, use document.getElementById directly to scroll without triggering router navigation:

// ❌ Triggers router navigation → activates intercepting route
<a href="#section">Go to section</a>

// ✅ Scrolls without router involvement
<button
  onClick={() => document.getElementById('section')?.scrollIntoView({ behavior: 'smooth' })}
>
  Go to section
</button>

This avoids the interception entirely because no navigation event fires.

Workaround 2: Guard the intercepting route with usePathname

In your @overlay/(.)menu/page.tsx, check that the previous pathname was different:

'use client';
import { usePathname } from 'next/navigation';
import { useRef, useEffect } from 'react';

export default function InterceptedMenuOverlay() {
  const pathname = usePathname();
  const initialPathname = useRef(pathname);

  // If the pathname was already /menu when this mounted,
  // we're in a hash/search-only update, not a true interception
  const isActualInterception = initialPathname.current !== '/menu';

  if (!isActualInterception) return null;

  return <MenuModal />;
}

The key insight: when a real interception happens (user navigated from another route to /menu), the component mounts fresh. When hash/search changes occur while already on /menu, the component re-renders but was already mounted from /menu.

Workaround 3: Use router.replace with scroll: false for search param state

For query-param-based UI state (tabs, filters), avoid <Link> and use router.replace with scroll: false:

import { useRouter } from 'next/navigation';

const router = useRouter();

// Update tab without triggering interception in some versions
router.replace(`/menu?tab=${tab}`, { scroll: false });

Note: This doesn't fully prevent interception re-evaluation in current versions, but combined with workaround 2 it handles the case cleanly.

Workaround 4: Use sessionStorage to distinguish intent (most reliable)

Set a flag before intentional intercepted navigations:

// When you WANT interception (e.g., from a list page)
<Link
  href="/menu"
  onClick={() => sessionStorage.setItem('intercept-menu', 'true')}
>
  Open Menu Overlay
</Link>

// In @overlay/(.)menu/page.tsx
const shouldIntercept = typeof window !== 'undefined'
  && sessionStorage.getItem('intercept-menu') === 'true';

useEffect(() => {
  sessionStorage.removeItem('intercept-menu');
}, []);

if (!shouldIntercept) return null;

Is this going to be fixed?

There are open issues tracking this behavior. The consensus is that intercepting routes should ideally only fire on pathname segment changes, not hash/search mutations. Until a fix lands, the combination of workaround 1 (scroll without router) + workaround 2 (pathname guard) covers most real-world cases without sessionStorage complexity.

Summary

Workaround	Handles hash?	Handles search params?	Complexity
Scroll via getElementById	✅ Yes	N/A	Low
usePathname mount guard	✅ Yes	✅ Yes	Low
router.replace + scroll:false	N/A	Partial	Low
sessionStorage intent flag	✅ Yes	✅ Yes	Medium