CDN Ignores Query Strings: When WordPress ?p= Is Swallowed, Baidu Landing Pages Redirect to the Homepage

Recently, while checking the website’s GA4 data, I noticed an anomaly that had been bothering me for a while:

The number of views on the site’s homepage was noticeably too high, and the overall user engagement duration was extremely short.

At first, I didn’t suspect the issue lay with the CDN’s Query String processing rules. It wasn’t until I actually clicked through to the site from Baidu search results this time that I finally connected the dots.

1. Abnormally High Homepage Views in GA4

In the GA4 report for the last 30 days, the site had approximately:

• 90,000 active users;
• 86,000 new users;
• 92,000 views;
• An average engagement duration of only 9 seconds per active user.

Among the top pages, the homepage title:

永夜 – 没有不值得去解决的问题，也没有不值得去学习的技术！

actually had 3,136 views.

I had found this number a bit strange before.

Based on the site’s actual content structure and traffic sources, users should mostly enter specific articles directly via search engines, rather than landing on the homepage in large numbers.

At the same time, the bounce rate for the homepage had reached 78.4%.

I couldn’t determine the cause at the time, so I could only suspect that it was caused by the tracking method or some abnormal traffic.

2. Discovering the Real Problem After Clicking a Baidu Search Result

I searched on Baidu for:

A Tour of Go

A Tour of Go

Baidu returned a historical search result from my blog.

Strangely, the search result snippet was clearly content from an article related to A Tour of Go, but the search result title had already changed to my site’s homepage title.

More importantly, after clicking this search result, the browser address bar showed:

https://www.shuijingwanwq.com/?p=15623

https://www.shuijingwanwq.com/?p=15623

But the page that actually opened was the site homepage.

This was clearly abnormal.

WordPress itself supports the access format:

?p=Article ID

?p=Article ID

Even if the site currently uses:

/year/month/day/ID/

/year/month/day/ID/

for its permalinks, ?p=ID is still a query method that WordPress can recognize.

For a currently valid article ID, WordPress / Polylang will normally redirect it to the official permalink.

The question is: why did the browser remain on /?p=15623 while the server returned the homepage?

3. Pinpointing the Issue in EdgeOne’s Query String Normalization Rule

To improve the cache hit rate and reduce cache fragmentation caused by a large number of URLs with meaningless query parameters, I had previously configured a rule in EdgeOne:

www 文章与公开列表页 Query String 归一化

This rule normalizes the Query String for public pages like the homepage, category pages, tag pages, and date archive pages.

The original rule already specifically excluded:

s
preview
preview_id
preview_nonce

s
preview
preview_id
preview_nonce

these parameters with actual functions.

However, it missed two very important WordPress parameters:

p
page_id

p
page_id

And below the rule, the following was configured:

Custom Cache Key
Query String: Ignore all

Custom Cache Key
Query String: Ignore all

as well as:

Origin Request Parameter Settings
Query String: Ignore all

Origin Request Parameter Settings
Query String: Ignore all

So when a user visits:

/?p=15623

/?p=15623

the URL path actually remains:

/

/

At the same time, it satisfies:

s does not exist
preview does not exist
preview_id does not exist
preview_nonce does not exist

s does not exist
preview does not exist
preview_id does not exist
preview_nonce does not exist

so it successfully triggered this normalization rule.

The final request chain effectively became:

User request:

/?p=15623

        ↓

EdgeOne ignores Query String

        ↓

Origin request:

/

        ↓

WordPress returns homepage

        ↓

Client receives:
HTTP 200 + Homepage HTML

User request:

/?p=15623

        ↓

EdgeOne ignores Query String

        ↓

Origin request:

/

        ↓

WordPress returns homepage

        ↓

Client receives:
HTTP 200 + Homepage HTML

This explains why:

Browser address remains /?p=15623

Browser address remains /?p=15623

but the page displayed is the homepage.

4. Origin Server Testing Further Confirms the Problem

To rule out an issue with WordPress itself, I bypassed the CDN and directly accessed the origin server for testing.

For:

/?p=15623

/?p=15623

the origin server directly returned:

HTTP/2 404

HTTP/2 404

But when going through EdgeOne, before the fix, it returned:

HTTP/2 200

HTTP/2 200

And in the page:

<link rel="canonical" href="https://www.shuijingwanwq.com/" />

<link rel="canonical" href="https://www.shuijingwanwq.com/" />

the title was also the homepage title.

This shows that EdgeOne had already dropped:

p=15623

p=15623

before returning to the origin.

To further confirm that WordPress’s ?p= mechanism itself was not the problem, I found another article that definitely exists:

https://www.shuijingwanwq.com/2026/09/04/27389/

https://www.shuijingwanwq.com/2026/09/04/27389/

I bypassed the CDN and directly requested:

https://www.shuijingwanwq.com/?p=27389

https://www.shuijingwanwq.com/?p=27389

The origin server normally returned:

HTTP/2 301
location: https://www.shuijingwanwq.com/2026/09/04/27389/
x-redirect-by: Polylang

HTTP/2 301
location: https://www.shuijingwanwq.com/2026/09/04/27389/
x-redirect-by: Polylang

Therefore, it can be confirmed that:

WordPress / Polylang’s compatibility with ?p=ID is completely normal; the problem lies in the CDN’s processing of the Query String.

5. Fix: Adding Protection for p and page_id

This time I did not overturn the original CDN caching strategy.

For a large number of public list pages, ignoring pure tracking parameters can still effectively reduce cache fragmentation.

I applied a minimal fix:

I continued to add to the original conditions:

p does not exist
page_id does not exist

p does not exist
page_id does not exist

This means that ordinary:

/?utm_source=xxx

/?utm_source=xxx

can still enter Query String normalization.

But:

/?p=27389

/?p=27389

because the p parameter exists, will no longer enter the “ignore all query strings” rule.

This way, EdgeOne will pass the complete request to WordPress.

6. After the Fix, Valid ?p= Has Resumed Normal 301s

After publishing the new rule, I requested via EdgeOne again:

https://www.shuijingwanwq.com/?p=27389

https://www.shuijingwanwq.com/?p=27389

It returned:

HTTP/2 301

x-redirect-by: Polylang

location:
<blockquote class="wp-embedded-content" data-secret="N18YKKmqyz"><a href="https://www.shuijingwanwq.com/2026/09/04/27389/">从 es-ES 首次上线复盘：我把 A Tour of Go 新增语言的 Production 流程又收敛了一轮</a></blockquote><iframe loading="lazy" class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; visibility: hidden;" title="《 从 es-ES 首次上线复盘：我把 A Tour of Go 新增语言的 Production 流程又收敛了一轮 》—Yongye" src="https://www.shuijingwanwq.com/2026/09/04/27389/embed/#?secret=SjwsbxONEA#?secret=N18YKKmqyz" data-secret="N18YKKmqyz" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>

eo-cache-status: MISS

HTTP/2 301

x-redirect-by: Polylang

location:
https://www.shuijingwanwq.com/2026/09/04/27389/

eo-cache-status: MISS

This shows that EdgeOne no longer swallows the p parameter.

The correct chain is restored to:

/?p=27389

        ↓

EdgeOne preserves p

        ↓

WordPress / Polylang

        ↓

301

        ↓

/2026/09/04/27389/

/?p=27389

        ↓

EdgeOne preserves p

        ↓

WordPress / Polylang

        ↓

301

        ↓

/2026/09/04/27389/

7. Invalid ?p= Also Restored to a True 404

The previous Baidu URL:

/?p=15623

/?p=15623

was requested again after the fix:

HTTP/2 404
eo-cache-status: MISS

HTTP/2 404
eo-cache-status: MISS

This is also the correct behavior.

The real problem before was not whether this URL should return a 404 or not, but rather:

A URL that should have returned a 404 was incorrectly converted to the homepage by the CDN, returning HTTP 200.

From an SEO perspective, this situation is even more troublesome than a normal 404.

What the search engine sees is:

URL:
/?p=15623

HTTP:
200

canonical:
/

title:
Homepage title

URL:
/?p=15623

HTTP:
200

canonical:
/

title:
Homepage title

This easily causes confusion between the URL, title, body content, and canonical.

The appearance in Baidu search results of:

Article snippet + Homepage title

is very likely related to this long-term incorrect response.

As for when Baidu discovered and saved the historical URL ?p=15623, it is now difficult to trace accurately.

But regardless of where this URL came from, the CDN should not arbitrarily delete the p parameter, which carries WordPress routing semantics.

8. GA4 Data Proves This Is Not a Low-Probability Issue

After the fix, I went back to GA4 and searched directly for:

?p=

?p=

The result was somewhat surprising.

In the past 30 days:

?p= related page views reached 2,479.

And in GA4, there appeared approximately:

1,856 different ?p= URLs.

And the previous number of views for the homepage title was:

3136

3136

2,479 is already approximately:

79%

79%

Of course, one cannot simply assume that:

3136 - 2479 = 657

3136 - 2479 = 657

is the true number of homepage views.

Because the specific times these visits occurred, the CDN cache status, and the rule effective time are not completely consistent.

But this data at least proves one thing:

The previously abnormally high homepage view count was very likely largely caused by these ?p= requests being incorrectly returned as the homepage.

9. This Also Explains Why User Engagement Duration Was So Short

The average engagement duration for all ?p= URLs combined in GA4 was only:

3 seconds

Many specific URLs even had only:

0 seconds
2 seconds
3 seconds
4 seconds

0 seconds
2 seconds
3 seconds
4 seconds

This phenomenon is also easy to explain now.

The user originally clicked on a specific article in Baidu or another search engine.

The user expected:

Search result
↓
Specific article

Search result
↓
Specific article

but actually got:

Search result
↓
/?p=xxxx
↓
CDN deletes p
↓
Homepage

Search result
↓
/?p=xxxx
↓
CDN deletes p
↓
Homepage

After clicking, the user found the content completely irrelevant, so they naturally left within a few seconds.

Therefore, this problem not only polluted:

• Homepage views;
• Page title statistics;
• Bounce rate;
• Average engagement duration;

but also actually affected:

• Search user experience;
• Actual article traffic;
• Search engine judgments of URLs;
• The credibility of the site’s overall behavioral data.

This is likely also one of the important reasons why the average engagement duration in GA4 has been only a few seconds recently.

10. English Site on Cloudflare Also Fixed Simultaneously

My main Chinese site:

www.shuijingwanwq.com

www.shuijingwanwq.com

currently uses EdgeOne.

The English site:

en.shuijingwanwq.com

en.shuijingwanwq.com

uses Cloudflare.

The English site also had a similar Query String normalization rule, so this time I simultaneously added:

p
page_id

p
page_id

protection.

Testing a valid article:

/?p=27398

/?p=27398

Result:

HTTP/2 301

location:
https://en.shuijingwanwq.com/2026/09/04/27398/

HTTP/2 301

location:
https://en.shuijingwanwq.com/2026/09/04/27398/

Testing a non-existent article:

/?p=999999999

/?p=999999999

Result:

HTTP/2 404

HTTP/2 404

Thus, the behavior of both CDNs has been realigned with the origin server.

11. Did Not Blindly Expand the Scope of Rule Modifications

After discovering the p issue, I also checked some other Query Strings that might have functional semantics, such as:

page
paged
cpage
feed
embed
rest_route
lang

page
paged
cpage
feed
embed
rest_route
lang

In the last 30 days:

paged=       0
cpage=       0
feed=        0
embed=       0
rest_route=  0
lang=        0

paged=       0
cpage=       0
feed=        0
embed=       0
rest_route=  0
lang=        0

page= was searched 94 times, but further inspection revealed they were mostly parameters like:

query-62-page=4

query-62-page=4

I then bypassed the CDN and compared the actual page content of:

/page/31/

/page/31/

and:

/page/31/?query-62-page=4

/page/31/?query-62-page=4

Although the hash of the full HTML was not exactly the same, the list of article links in the page was completely identical.

So there is no evidence that it caused an actual problem similar to p.

I ultimately decided:

To only fix issues that have real traffic data and tested evidence, and not massively increase CDN rule complexity all at once due to theoretical risks.

Currently, I continue to protect:

s
preview
preview_id
preview_nonce
p
page_id

s
preview
preview_id
preview_nonce
p
page_id

Other parameters will continue to be observed for now.

Summary

On the surface, this problem appeared to be just:

Why are homepage views so high?

But after the final investigation, it was actually a complete chain of issues involving the CDN, WordPress, search engines, and GA4:

Baidu historical ?p= URL
        ↓
EdgeOne Query String normalization
        ↓
p parameter deleted
        ↓
Origin server receives /
        ↓
Returns homepage HTTP 200
        ↓
User sees wrong page
        ↓
GA4 page_location remains ?p=
        ↓
page_title becomes homepage title
        ↓
Homepage views amplified
        ↓
Engagement duration and bounce rate worsen simultaneously

Baidu historical ?p= URL
        ↓
EdgeOne Query String normalization
        ↓
p parameter deleted
        ↓
Origin server receives /
        ↓
Returns homepage HTTP 200
        ↓
User sees wrong page
        ↓
GA4 page_location remains ?p=
        ↓
page_title becomes homepage title
        ↓
Homepage views amplified
        ↓
Engagement duration and bounce rate worsen simultaneously

The real problem was not “using Query String normalization” itself.

Having the CDN ignore parameters like UTM that do not change page content is indeed beneficial for improving cache hit rates.

The problem was:

Parameters that change WordPress routing and page content should not be filtered out along with ordinary tracking parameters.

What was missed this time were:

p
page_id

p
page_id

And according to GA4 data, ?p= generated 2,479 views in the past 30 days.

If you only look at the CDN configuration itself, these two parameters are easily overlooked.

But what ultimately exposed the problem was a very ordinary operation:

Clicking through to the site from Baidu search results.

Sometimes, real user access paths are indeed more likely to reveal problems than simply looking at monitoring and configurations.