A horizontal scroll bar appears on the WordPress page? A complete check record from CSS to a block editor

From Classical to Block: Theme Migration

(1) From Hueman to Twenty Twenty-Five, Topic Switching with Multilingual Menu Configuration

(2) In a WordPress 2025 topic, move the Polylang language switch to the full record in the upper right corner

(3) WordPress Twenty Twenty-Five Global Width Layout Practical Notes: Widescreen Full-Scale + Large Screen Limited Wide Configuration Scheme

(4) Practice｜WordPress Twenty-Five Block Theme Text Blog Home Transform the Classic Two-Column Homepage

(5) WordPress Twenty Twenty-Five Two-column homepage transformation: Text Blog Small picture list template complete practical record

(6) Debugging record of the beautification and rendering mechanism of the drop-down menu of the category list

(7) Fixed the issue of “getting dissatisfaction” in the sidebar: WordPress 2025 theme calendar style optimization

(8) Add the multi-language “Personal Brand” block to the sidebar of the blog homepage

(9) Troubleshooting and Repair of One FSE Page Loss: From Pure Layout Template to Query Loop

(10) WordPress 2025 Theme + Polylang: Fix a full record of the missing language directory for the calendar link

(11) Optimize WordPress 2025 Themeser: A complete remodeling record of multilingual navigation, social links and archive drop-down bars

(12) From single column to two columns: the practical record of the sidebar and list structure of the WordPress category page unified first page

(13) Say goodbye to uneven! Create a modern label cloud for 2025 themes only with CSS

(14) Is the search result page too long? I did a “break away” for the WordPress 2025 theme

(15) Compatibility restoration practice of WordPress calendar in Polylang multi-language environment

(16) WordPress Theme Migration: Does Emoji Process Code Need to Keep?

(17) WordPress Tab NoIndex Optimization: Practical Sharing from Theme Migration to Code Refactoring

(18) WordPress Console Error Troubleshooting Transcript: From jQuery conflict to Baidu statistical warning

(19) From AD INSERTER to WPCode: CTA configuration migration and priority implementation

(20) Remember a full record of a wordpress 500 fatal error checking caused by wpcode shortcode

(21) Remember a WordPress 2025 Theme Logo and Favicon’s Tossing Journey

(22) From AD Inserter to WPCode: CTA configuration migration and optimization practices

(23) WPCode code snippet insertion order problem: the gap between theory and practice

(24) Optimize the list spacing of popular articles in WordPress to improve your reading experience

(25) A horizontal scroll bar appears on the WordPress page? A complete check record from CSS to a block editor

When I was sorting out the ‘About Me & Partner’ page of the blog recently, I found that the bottom of the page suddenly appearedHorizontal scroll bar.

At first, I thought there was a problem with CSS, but I finally found out that the real reason turned out to be ‘Full Width’ settings for the Gutenberg block.

This article records the complete investigation process, and I hope that when I encounter similar problems again in the future, I can quickly locate them.

problem

page:

https://www.shuijingwanwq.com/en/about-me-contact-2/

https://www.shuijingwanwq.com/en/about-me-contact-2/

A horizontal scroll bar appears at the bottom of the PC browser.

The content of the page itself does not have a particularly wide picture, and there is no table, so the first reaction is a bit strange.

Step 1: Positioning Who Broaden the Page

First open the browser developer tool (F12).

Console executes:

[...document.querySelectorAll('*')]
.filter(el => el.scrollWidth > document.documentElement.clientWidth)
.map(el => ({
    tag: el.tagName,
    class: el.className,
    id: el.id,
    width: el.scrollWidth
}))

[...document.querySelectorAll('*')]
.filter(el => el.scrollWidth > document.documentElement.clientWidth)
.map(el => ({
    tag: el.tagName,
    class: el.className,
    id: el.id,
    width: el.scrollWidth
}))

The output is similar:

HTML
BODY
wp-site-blocks
MAIN
entry-content alignfull

HTML
BODY
wp-site-blocks
MAIN
entry-content alignfull

The most important line here:

entry-content alignfull

entry-content alignfull

The real ultra-wide is the entire body area, not a picture or a div.

Step 2: Doubt CSS

At first I doubted:

• Picture wide
• iframe
• table
• pre
• A plugin outputs a fixed width

Even if you are ready to write directly:

body{
    overflow-x:hidden;
}

body{
    overflow-x:hidden;
}

But this just hides the problem and doesn’t really solve it.

Therefore, there is no continuing to modify to CSS.

Step 3: Check the page editor

Since the problem occurs in:

entry-content alignfull

entry-content alignfull

Then it means that the problem is likely to come from Gutenberg.

Open the page editor.

View the outermost group.

find:

对齐：

全幅（Full Width）

对齐：

全幅（Full Width）

So try to modify it to:

宽幅（Wide Width）

宽幅（Wide Width）

save.

Refresh the page.

The horizontal scroll bar disappears immediately.

Ultimate reason

The real problem is not CSS.

but:

Group

Alignment

Full Width

Group

Alignment

Full Width

Modified to:

Wide Width

Wide Width

back to normal afterwards.

Explain that there is a compatibility problem with the current theme (twenty twiny-five) and the current layout of my website. Under some pages, there is a compatibility problem with the calculation of full width.

Why can the console be positioned?

Because the executed js will find out:

scrollWidth > viewport

scrollWidth > viewport

That is:

Which elements have actually exceeded the browser width.

If output:

img

img

Description The picture is super wide.

If output:

table

table

The description table is super wide.

If output:

pre

pre

Description The code block is super wide.

And this output is:

entry-content alignfull

entry-content alignfull

So quickly locked to the entire body container.

A set of checks I have summarized

Later, when I encounter a horizontal scroll bar in the WordPress page, I am going to check in the following order.

First step

console:

[...document.querySelectorAll('*')]
.filter(el => el.scrollWidth > document.documentElement.clientWidth)

[...document.querySelectorAll('*')]
.filter(el => el.scrollWidth > document.documentElement.clientWidth)

Find out the really ultra-wide elements.

Second step

If it is:

img
table
iframe
pre

img
table
iframe
pre

Check the corresponding content directly.

Third step

If it is:

entry-content

wp-block-group

alignfull

entry-content

wp-block-group

alignfull

Priority check:

Group

Columns

Cover

Gallery

Group

Columns

Cover

Gallery

Is it set to:

Full Width

Full Width

If not necessary, change to:

Wide Width

Wide Width

Retest again.

Fourth step

Finally, I considered modifying the CSS.

Don’t start with:

overflow-x:hidden;

overflow-x:hidden;

Otherwise just cover up the problem and not really fix it.

This experience

The biggest gain this time is not to solve the horizontal scroll bar.

Instead, a set of checks that can be reused in the future is formed:

First use the browser developer tool to locate the ultra-wide element, then go back to the WordPress block editor to check the corresponding block, and finally consider CSS repair.

Compared with direct modification, this method is positioned faster and easier to find the real problem.