When a Page Refuses to Scroll
A page that will not scroll is almost never a WordPress fault. Something left a scroll lock switched on, and the cure is to find what opened it rather than to force the page open with CSS.
Quick fix: click on an empty part of the page and press the End key. If the page jumps to the bottom, the document scrolls fine and a script is intercepting your mouse wheel. If nothing moves, something has applied a scroll lock to the page itself. Those two findings lead to completely different repairs, and the test costs one keypress.
The trap is reaching straight for custom CSS that forces the body to scroll. It works, which is exactly the problem: the underlying bug stays, and now every modal and mobile menu on the site scrolls its background while open.
Why a page stops scrolling
Browsers scroll by default. Scrolling stops only when something deliberately prevents it, and in practice there are four mechanisms:
- An overflow lock. A script sets
overflow: hiddenon thehtmlorbodyelement — usually by adding a class such asmodal-open,menu-openorno-scroll— and is meant to remove it when the popup closes. If the close handler errors or the popup never became visible, the lock stays. - A fixed-position body. The mobile version of the same pattern pins the body in place and restores its position on close, with the same failure mode.
- A clipped container. A wrapper with a fixed height and hidden overflow means content below the fold is not merely unreachable, it is not being laid out at all.
- Hijacked wheel events. Smooth-scroll, parallax and one-page-scroll libraries take over scrolling and compute the document height themselves. If they measure before images load, or two of them run at once, scrolling stalls partway.
Narrow it in three checks
| Test | Result | What it means |
|---|---|---|
| Press End or Page Down | Page moves | Document scrolls; a script owns the wheel |
| Press End or Page Down | Nothing | Overflow lock or clipped container |
| Load with JavaScript disabled | Scrolls fine | A script is responsible, not the CSS |
| Load with JavaScript disabled | Still stuck | Static CSS — theme, builder or custom |
| Resize the window narrower | Suddenly scrolls | Breakpoint-specific component, usually a menu |
| Scrollbar visible but inert | — | Wheel and key handlers intercepted |
Inspect the body element
Open developer tools, select the <body> element and read two things: its class list and its computed overflow and position values.
A class like menu-open sitting there on a page where no menu is open is a complete diagnosis. So is overflow: hidden on html or body with the page scrolled to the top. Remove the class in the inspector — if the page immediately scrolls, you have confirmed the mechanism and now only need to find which component applies it.
To find that component, check the console for JavaScript errors first. A script that throws before reaching its cleanup code leaves the lock behind, and the error names the file. Where the console is clean, the culprit is usually a popup, cookie notice, age gate or off-canvas menu that opened with zero opacity or off-screen — invisible, but locked.
If instead you find a parent element with a fixed height and hidden overflow, that is a layout fault. Look at what set the height: a full-height hero section, a builder row configured to viewport height, or custom CSS added while chasing a different problem. Where custom CSS lives in WordPress covers the places to check, including the ones people forget they used.
Confirm which component owns it
Once you know it is a script, isolate normally rather than guessing.
- Test a default theme. If the page scrolls, the theme or its bundled scripts are responsible.
- Bisect plugins rather than switching them off one at a time. Popup, cookie-consent and mega-menu plugins are the usual suspects, and two of them applying scroll locks to the same page is a classic pairing — how to isolate plugin conflicts covers the halving method.
- Check one page against another. If only one page fails, the cause is on that page: an embedded element, a specific block, or a popup rule targeting that URL.
- Check whether stylesheets loaded at all. A half-loaded page can lay out strangely enough to look locked, which CSS not loading in WordPress covers separately.
Fix the cause, then verify properly
Repair the component: update or replace the plugin whose script errors, correct the fixed height, or remove the duplicate smooth-scroll library so only one owns the wheel. Then test the behaviour you were about to break — open every modal and off-canvas menu on the site, confirm the background does not scroll behind them, and confirm scrolling returns when each one closes.
Test at a narrow width too, since mobile layouts open different components and this fault is disproportionately a mobile one. Fixing a WordPress site that misbehaves on mobile covers the other faults that show up only at small breakpoints.
Frequently asked
- Mobile layouts open different components, most often an off-canvas menu that applies a scroll lock when it opens. If its close handler never runs, or the menu opens invisibly at that breakpoint, the lock stays applied while nothing appears on screen.
- It restores scrolling and hides the cause, which means every modal and off-canvas menu on the site now scrolls its background while open. Use it as a temporary measure on a live site if you must, but treat finding the script that left the lock on as the actual repair.
- The document itself is scrollable, so nothing is locked. A script is intercepting wheel events, typically a smooth-scrolling or parallax library that failed to initialise correctly or is fighting a second script doing the same job.