Debugging a Privacy Page Scroll Jump Bug in Next.js

I ran into a page-specific frontend bug on a Next.js site: the Privacy Policy page kept jumping up and down after loading.

The confusing part was that the problem only happened on the Privacy page. Other pages were stable. That meant the issue was probably not a global layout problem, not a general browser problem, and not a simple CSS spacing issue.

This note documents how I debugged the Privacy page as its own scroll behavior bug, instead of continuing to guess from common causes.

The observed behavior was simple:

This kind of bug is frustrating because it does not always show up as an obvious error in the console. The page renders, the content exists, and the route returns 200. But the reading experience is broken because the browser keeps changing the scroll position.

The first wrong assumption was treating it like a generic layout issue.

Common guesses include:

Those can be valid causes on some pages, but they did not explain why only the Privacy page kept jumping.

The better question was:

After inspecting the Privacy page source, the suspicious pattern became clearer.

The page still had many internal hash links and section targets:

At the same time, the site had global smooth scrolling enabled.

That combination made the Privacy page different from normal article pages. It had many built-in scroll targets and several ways for the browser to reposition the document.

The likely root cause was not one single line of code. It was the interaction between several scroll behaviors:

A browser can remember a previous scroll position. A hash in the URL can ask the browser to jump to a section. Smooth scrolling can animate that movement. React hydration can then change timing again.

When all of these exist on the same page, the result can look like the page is moving on its own.

The Privacy page did not actually need interactive hash navigation.

A Privacy Policy page is mostly a reading page. It does not need quick links that jump the user around while the browser is also trying to restore scroll position.

So the fix direction was:

This keeps the Privacy page stable without changing scroll behavior across the whole site.

The first fix was to remove clickable internal hash links from the Privacy page.

Instead of rendering quick links like this:

I changed the quick-link area into a plain topic list.

The list still helps the reader understand the page structure, but it no longer triggers browser-level hash navigation.

Removing links was not enough. If the page still had section ids, a stale hash in the URL could still target those sections.

So I also removed the section-level scroll targets from the Privacy page:

That made the page behave more like a normal document instead of a page with many addressable scroll targets.

The next fix was to add a page-specific scroll stabilizer.

The stabilizer is only for the Privacy page. Its job is to keep this page from restoring an old scroll position or reacting to a stale hash.

The behavior is:

This is important because a global scroll fix would be too risky. Other pages may still need normal browser scroll restoration.

The site used smooth scrolling globally. Smooth scrolling is usually fine for anchor navigation, but it can make debugging scroll jumps harder because it turns position changes into visible movement.

Instead of removing smooth scrolling globally, I added a page-specific class:

Then the Privacy page can temporarily disable smooth scroll while it stabilizes the initial scroll position.

This keeps the fix narrow. The Privacy page becomes stable without changing the interaction behavior of unrelated pages.

A React component runs after the page starts hydrating. For a scroll bug, that may be too late because the browser can restore position before React finishes loading.

So I added an early guard directly in the Privacy page output.

The purpose was:

This is the difference between fixing a jump after it happens and preventing the jump from happening in the first place.

After the changes, I verified both the source and the actual served page.

The checks were:

This step matters because checking source files alone is not enough. A dev server can serve stale output, and a page can still contain generated HTML that differs from what I expected.

Before the fix, the Privacy page had multiple scroll triggers:

After the fix, the Privacy page became a stable reading page:

The main gotcha is that scroll bugs can be caused by several small features working together.

A hash link is normal. Smooth scroll is normal. Browser scroll restoration is normal. Sticky navigation is normal. Hydration is normal.

But on a long policy page, all of them together can create unstable behavior.

The practical lesson is:

The mental model I use now is:

A stable page should not have unnecessary scroll targets. If the page is mainly for reading, a plain table of contents can be safer than hash navigation.

For a page-specific scroll jump bug, I would check:

This checklist is more useful than guessing from generic layout bugs.

The final takeaway is simple:

For this bug, the best fix was not adding more JavaScript everywhere. It was removing unnecessary hash navigation, disabling smooth scroll only where needed, preventing browser scroll restoration on the Privacy page, and verifying the actual served HTML.

That made the Privacy page behave like a stable reading page instead of a page with competing scroll instructions.