Explain Shallow Routing in Next.js Pages Router

What's really being asked

Your understanding of the boundary between client-side navigation and server-side data fetching in the Next.js Pages Router. Specifically, it probes whether you know how to update the URL and browser history without triggering a full page transition that re-runs getServerSideProps, getStaticProps, or getInitialProps. Interviewers care about this because misuse causes unnecessary server load, layout flicker, and janky user experiences.

The full answer

First, a precise definition of shallow routing as a router.push or router.replace call with the shallow option set to true, which mutates the URL but skips data method execution on the client. Second, the core problem it solves: synchronizing client-only UI state such as active tabs, open modals, or search filters into the query string so URLs remain shareable and bookmarkable without hammering the server on every interaction. Third, concrete scenarios where it is appropriate, including pagination controls, dashboard date pickers, and e-commerce filter sidebars that manage state entirely in the browser after the initial payload. Fourth, the limitations: it only works for same-page URL changes in the Pages Router, it does not prevent the React page component from re-rendering, it does not skip client-side data fetching you trigger manually, and it is completely unavailable in the App Router.

The mistakes people make

Candidates often claim shallow routing prevents React re-renders entirely, when in reality it only prevents data fetching method re-execution. Another red flag is asserting that shallow routing works across different pages or inside the App Router. Some engineers also confuse shallow routing with shallow rendering from testing libraries, or they suggest using it to avoid server work on the initial request rather than on subsequent client-side transitions.

What usually comes next

The interviewer may ask how you would implement equivalent behavior in the App Router using useSearchParams and client-side state without re-fetching RSC payloads. They might ask how scroll restoration behaves during a shallow route change, or how you handle a direct page load on a URL that was designed to be reached only through shallow routing. Another common follow-up is whether you should use router.replace instead of router.push to avoid polluting browser history with every filter change.

A concrete example

Imagine an analytics dashboard that fetches a summary dataset via getServerSideProps on initial load. A user wants to filter by date range, and the application stores that range in the query string so reports can be shared. Without shallow routing, every date change calls getServerSideProps again, adding two hundred to five hundred milliseconds of latency and a database hit. By passing shallow true to router.push, the URL updates instantly, the existing data stays in memory, and the client applies the date filter locally. The only caveat is that if the user refreshes the page, the server must now handle the date query on initial load, which requires the data method to support that parameter.