【宋词】《六丑》 彭元逊：似东风老大，那复有、当时风气。有情不收，江山身是寄。浩荡何世。但忆临官道，暂来不住，便出门千里。痴心指望回风坠。

永夜

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

After Migrating a WordPress English Site to a Subdomain: Adjust Yoast Sitemaps, Thin Content Tags, and Search Engine Submissions

作者：

永夜

在

,
Post Views: 12

Recently, I migrated the WordPress English site from the original:

Plaintext
https://www.shuijingwanwq.com/en/

to an independent subdomain:

Plaintext
https://en.shuijingwanwq.com/

The Chinese site still uses:

Plaintext
https://www.shuijingwanwq.com/

The website uses Polylang’s multiple domain mode. The Chinese and English sites share the same WordPress installation, database, and Nginx configuration, but identify the current language based on the accessed domain.

At the same time, I re-enabled Yoast SEO. Once enabled, the WordPress native sitemap:

Plaintext
https://www.shuijingwanwq.com/wp-sitemap.xml

was gradually replaced by the new sitemap generated by Yoast SEO:

Plaintext
https://www.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/sitemap_index.xml

This adjustment was not just about replacing a sitemap URL. It also involved thin content tags, caching, multiple domain identification, and resource updates across search engine platforms like Google, Bing, 360, Baidu, and Sogou.

This article documents the complete troubleshooting and resolution process.

1. Current Website Environment

The main components involved in this adjustment are as follows:

  • WordPress
  • Polylang multiple domain mode
  • Yoast SEO
  • W3 Total Cache
  • Redis Object Cache
  • Cloudflare
  • Tencent Cloud EdgeOne
  • WPCode
  • OneinStack Nginx
  • Google Search Console
  • Bing Webmaster Tools
  • 360 Webmaster Platform
  • Baidu Search Resource Platform
  • Sogou Resource Platform

The division of labor between domains and CDNs is:

Plaintext
www.shuijingwanwq.com
        ↓
     EdgeOne
        ↓
  WordPress Chinese site


en.shuijingwanwq.com
        ↓
    Cloudflare
        ↓
  WordPress English site

Although the two domains use different CDNs, the origin server uses the same WordPress directory:

Plaintext
/data/wwwroot/www.shuijingwanwq.com/

Therefore, the handling of caching and search engine verification files differs from that of two completely independent WordPress sites.

2. Confirming the English Site Yoast Sitemap is Working Properly

After enabling Yoast SEO on the English site, the new sitemap index URL is:

Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml

Opening it in a browser reveals multiple sub-sitemaps, such as:

Plaintext
post-sitemap.xml
post-sitemap2.xml
page-sitemap.xml
category-sitemap.xml
post_tag-sitemap.xml
post_tag-sitemap2.xml
...
series-sitemap.xml

In this check, the English site’s Sitemap Index contained a total of 15 sub-sitemaps.

All URLs used:

Plaintext
https://en.shuijingwanwq.com/

None were mixed with:

Plaintext
https://www.shuijingwanwq.com/en/

Nor did the canonical tags point to the Chinese domain.

[Figure 1, English site Yoast sitemap_index.xml page]
[Figure 1, English site Yoast sitemap_index.xml page]

3. Setting noindex for Thin Content Tags and Excluding Them from the Sitemap

The website already has a large number of historical tags, many of which are English tags associated with only one or two articles.

If all these tag pages were allowed to be indexed, it would easily generate a large number of archive pages with low content value. Therefore, I ultimately set the rule to:

When a tag is associated with fewer than 3 articles, output noindex, follow and exclude it from the Yoast XML Sitemap.

The complete code used in WPCode is as follows:

PHP
/**
 * 薄内容标签页 SEO 处理：
 * 1. 标签文章数量少于 3 时，通过 Yoast SEO 输出 noindex。
 * 2. 同时将这些标签从 Yoast XML Sitemap 中排除。
 */

$swq_thin_tag_threshold = 3;

/**
 * 修改标签归档页的 Yoast robots 输出。
 */
add_filter(
    'wpseo_robots',
    function ( $robots ) use ( $swq_thin_tag_threshold ) {

        if ( ! is_tag() ) {
            return $robots;
        }

        $tag = get_queried_object();

        if (
            ! $tag instanceof WP_Term ||
            ! isset( $tag->count )
        ) {
            return $robots;
        }

        if ( (int) $tag->count < $swq_thin_tag_threshold ) {
            return 'noindex, follow';
        }

        return $robots;
    },
    20
);

/**
 * 将薄内容标签从 Yoast XML Sitemap 中排除。
 */
add_filter(
    'wpseo_exclude_from_sitemap_by_term_ids',
    function ( $excluded_term_ids ) use ( $swq_thin_tag_threshold ) {

        global $wpdb;

        $thin_tag_ids = $wpdb->get_col(
            $wpdb->prepare(
                "
                SELECT term_id
                FROM {$wpdb->term_taxonomy}
                WHERE taxonomy = %s
                AND count < %d
                ",
                'post_tag',
                $swq_thin_tag_threshold
            )
        );

        if ( empty( $thin_tag_ids ) ) {
            return $excluded_term_ids;
        }

        return array_values(
            array_unique(
                array_merge(
                    array_map( 'intval', (array) $excluded_term_ids ),
                    array_map( 'intval', $thin_tag_ids )
                )
            )
        );
    }
);

The WPCode settings are:

Plaintext
Code type: PHP Snippet
Insert method: Auto Insert
Location: Frontend Only
Status: Active

The two parts of this code serve different purposes:

Plaintext
wpseo_robots

controls the robots meta tag of the tag archive page.

Plaintext
wpseo_exclude_from_sitemap_by_term_ids

excludes the corresponding term IDs from the Yoast Sitemap.

4. Why Cache Clearing is Necessary After Modifying the Code

The English site currently has multiple layers of caching:

Plaintext
WordPress / Yoast generated content
        ↓
W3 Total Cache Object Cache
        ↓
W3 Total Cache Page Cache
        ↓
Cloudflare Cache
        ↓
Browser or search engine

Clearing only one layer might still result in seeing the old Sitemap or old HTML.

1. Clearing the English Domain Object Cache

I used the script I organized previously:

Bash
/root/bin/w3tc-flush-host-object-cache en.shuijingwanwq.com

The output was as follows:

Plaintext
Started WordPress with the following Host and invoked W3TC Object Cache cleanup:
en.shuijingwanwq.com

This script starts WordPress using the specified Host, preventing it from incorrectly loading the configuration for the Chinese domain in the Polylang multiple domain environment.

2. Clearing the XML Cache in Cloudflare

Since this code change primarily affects the tag Sitemaps, I went to the Cloudflare dashboard:

Plaintext
Caching
→ Configuration
→ Custom Purge
→ URL

and purged the following URLs all at once:

Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/post_tag-sitemap.xml
https://en.shuijingwanwq.com/post_tag-sitemap2.xml
https://en.shuijingwanwq.com/post_tag-sitemap3.xml
https://en.shuijingwanwq.com/post_tag-sitemap4.xml
https://en.shuijingwanwq.com/post_tag-sitemap5.xml
https://en.shuijingwanwq.com/post_tag-sitemap6.xml
https://en.shuijingwanwq.com/post_tag-sitemap7.xml
https://en.shuijingwanwq.com/post_tag-sitemap8.xml
https://en.shuijingwanwq.com/post_tag-sitemap9.xml

Cloudflare supports pasting multiple URLs at once, one address per line.

[Figure 2, Cloudflare custom purge of Sitemap URLs]
[Figure 2, Cloudflare custom purge of Sitemap URLs]

5. Batch Checking 9 Tag Sitemaps Using curl

Browser screenshots only show a small portion of the XML content, making them unsuitable for checking nearly a thousand tag URLs.

Therefore, I used the following Bash script to batch fetch all tag Sitemaps from the English site:

Bash
tmp="/tmp/en-tag-sitemap-check"

rm -rf "$tmp"
mkdir -p "$tmp"

curl -fsSL "https://en.shuijingwanwq.com/sitemap_index.xml" \
| grep -oE 'https://en\.shuijingwanwq\.com/post_tag-sitemap[0-9]*\.xml' \
| sort -V \
> "$tmp/maps.txt"

: > "$tmp/all-urls.txt"

while IFS= read -r map
do
    file="$tmp/$(basename "$map")"

    status="$(curl -sS -L \
        -o "$file" \
        -w '%{http_code}' \
        "$map")"

    grep -oE '<loc>[^<]+</loc>' "$file" \
    | sed -E 's#</?loc>##g' \
    > "$file.urls"

    cat "$file.urls" >> "$tmp/all-urls.txt"

    total="$(wc -l < "$file.urls")"
    wrong_host="$(grep -Evc '^https://en\.shuijingwanwq\.com/' "$file.urls" || true)"
    wrong_path="$(grep -Evc '^https://en\.shuijingwanwq\.com/tag/' "$file.urls" || true)"

    printf '%-28s HTTP=%s  URLs=%s  错误域名=%s  非标签路径=%s\n' \
        "$(basename "$map")" \
        "$status" \
        "$total" \
        "$wrong_host" \
        "$wrong_path"

done < "$tmp/maps.txt"

map_count="$(wc -l < "$tmp/maps.txt")"
url_count="$(wc -l < "$tmp/all-urls.txt")"

echo
echo "站点地图文件数：$map_count"
echo "标签 URL 总数：$url_count"
echo
echo "异常网址："

grep -Ev '^https://en\.shuijingwanwq\.com/tag/' \
    "$tmp/all-urls.txt" \
    | head -n 20

The actual output was:

Plaintext
post_tag-sitemap.xml         HTTP=200  URLs=86  Wrong domain=0  Non-tag path=0
post_tag-sitemap2.xml        HTTP=200  URLs=123 Wrong domain=0  Non-tag path=0
post_tag-sitemap3.xml        HTTP=200  URLs=110 Wrong domain=0  Non-tag path=0
post_tag-sitemap4.xml        HTTP=200  URLs=113 Wrong domain=0  Non-tag path=0
post_tag-sitemap5.xml        HTTP=200  URLs=107 Wrong domain=0  Non-tag path=0
post_tag-sitemap6.xml        HTTP=200  URLs=107 Wrong domain=0  Non-tag path=0
post_tag-sitemap7.xml        HTTP=200  URLs=115 Wrong domain=0  Non-tag path=0
post_tag-sitemap8.xml        HTTP=200  URLs=92  Wrong domain=0  Non-tag path=0
post_tag-sitemap9.xml        HTTP=200  URLs=122 Wrong domain=0  Non-tag path=0

The check results indicate:

  • All 9 tag Sitemaps returned HTTP 200
  • No wrong domains
  • No old /en/ paths
  • All URLs belong to the English site /tag/ path
[Figure 3, Terminal batch check of 9 tag Sitemaps]
[Figure 3, Terminal batch check of 9 tag Sitemaps]

6. Sitemap Misjudgment Caused by Duplicate Tags

During the batch check, I found the following URL appearing multiple times:

Plaintext
https://en.shuijingwanwq.com/tag/cdn-acceleration/

Upon further inspection of the WordPress dashboard, I found that there were two tags with the same name and slug in the database.

[Figure 4, Two duplicate CDN acceleration tags in the WordPress dashboard]
[Figure 4, Two duplicate CDN acceleration tags in the WordPress dashboard]

Another typical example is:

Plaintext
https://en.shuijingwanwq.com/tag/wordpress-performance-optimization/

The database contains two tags with the same slug:

Plaintext
One tag is associated with 3 articles
The other tag is associated with 2 articles

The public archive page actually displays 3 articles, and the robots tag is:

HTML
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

The canonical is:

HTML
<link rel="canonical" href="https://en.shuijingwanwq.com/tag/wordpress-performance-optimization/" />

Keeping this URL in the Sitemap is correct.

One thing to note here:

Yoast’s exclusion filter works by term ID, while search engines ultimately see the URL.

When multiple term IDs share the same slug, checking the URL based solely on the article count of one specific tag in the database may lead to false positives.

Therefore, when verifying thin tags, you should prioritize checking tags that meet these criteria:

  • Unique slug
  • Clear language
  • Fewer than 3 articles
  • Do not share a public URL with other tags

for inspection.

7. Verifying Whether the Thin Content Tag Rule is Actually in Effect

I ultimately selected 5 English thin content tags without duplicate slugs for inspection:

Plaintext
Microphone: 1 article
mouse: 2 articles
(Failed) net: 1 article
-With map: 1 article
./yii file: 1 article

The check results for all of them were:

Plaintext
HTTP status: 200
Robots: &lt;meta name='robots' content='noindex, follow' />
Sitemap: Excluded

For example:

Plaintext
Tag name: Microphone
Tag slug: microphone
Database article count: 1
URL: https://en.shuijingwanwq.com/tag/microphone/
HTTP status: 200
Robots: &lt;meta name='robots' content='noindex, follow' />
Sitemap: Excluded

This proves that both parts of the WPCode functionality are working:

  1. Thin content tag pages output noindex, follow
  2. Thin content tag URLs no longer appear in the Yoast XML Sitemap
[Figure 5, Verification results of thin content tag robots and Sitemap exclusion]
[Figure 5, Verification results of thin content tag robots and Sitemap exclusion]

8. Adjustments in Google Search Console

Google Search Console previously primarily used:

Plaintext
https://www.shuijingwanwq.com/

and the old WordPress Sitemap:

Plaintext
https://www.shuijingwanwq.com/wp-sitemap.xml

After this adjustment, in the domain resource:

Plaintext
shuijingwanwq.com

I submitted:

Plaintext
https://www.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/sitemap_index.xml

Both Sitemaps ultimately showed:

Plaintext
Status: Success

I then deleted the old submission record in Google Search Console:

Plaintext
https://www.shuijingwanwq.com/wp-sitemap.xml

This only deleted the submission record in Search Console, not the WordPress route on the server.

Adding an Independent URL Prefix Property for the English Site

Although the domain property already covers all subdomains, to separately observe the English site’s data, I also added:

Plaintext
https://en.shuijingwanwq.com/

as a URL prefix property.

After adding it, I can individually view the English site’s:

  • Search clicks
  • Impressions
  • Query keywords
  • Page indexing status
  • HTTPS status
  • Sitemap crawl results
  • Changes from migrating from the old /en/ path to the new subdomain

The English property automatically displayed:

Plaintext
/sitemap_index.xml
Status: Success
[Figure 6, Both www and en Sitemaps are successful in Google Search Console]
[Figure 6, Both www and en Sitemaps are successful in Google Search Console]

9. Adjustments in Bing Webmaster Tools

Bing Webmaster Tools already had several historical Sitemaps, including:

Plaintext
https://www.shuijingwanwq.com/wp-sitemap.xml
https://www.shuijingwanwq.com/sitemap_index.xml
https://shuijingwanwq.com/sitemap.xml

I then manually submitted:

Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml

It initially showed:

Plaintext
Processing

After refreshing, it changed to:

Plaintext
Success

The English Sitemap initially showed 15 discovered URLs because Bing first read the 15 sub-sitemaps in the Sitemap Index, and it will continue to process the page URLs within those sub-sitemaps subsequently.

One rather peculiar aspect is that Bing’s current interface does not provide an obvious entry point for deleting old Sitemaps.

Whether on the list page or the detail page, the right-click menu only offers:

Plaintext
Resubmit

It lacks the “Remove Sitemap” option found in Google Search Console.

Therefore, keeping historical Sitemap records in Bing does not mean the website still uses the old Sitemap as the primary entry point. The ones currently in official use are still:

Plaintext
https://www.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/sitemap_index.xml
[Figure 7, Both Chinese and English Sitemap statuses are successful in Bing]
[Figure 7, Both Chinese and English Sitemap statuses are successful in Bing]

10. Adjustments in the 360 Webmaster Platform

The 360 Webmaster Platform requires Sitemaps to be bound to verified sites.

Initially, the site list only contained:

Plaintext
www.shuijingwanwq.com

I could not directly submit:

Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml

under that site. Therefore, I first needed to go to:

Plaintext
Site Management
→ Add Subdomain

to add:

Plaintext
en.shuijingwanwq.com

Here, I should select “Add Subdomain” rather than “Add Website”, because en is a subdomain under an existing main domain.

After adding it:

  1. Enable HTTPS for the English site
  2. Switch the current site to en.shuijingwanwq.com
  3. Go to Sitemap submission
  4. Submit:
Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml

After successful submission, 360 displayed the update cycle and a “Manual Update” entry.

Ultimately, both the Chinese and English sites in 360 use Yoast’s:

Plaintext
sitemap_index.xml
[Figure 8, 360 adds en subdomain and submits the English Sitemap]
[Figure 8, 360 adds en subdomain and submits the English Sitemap]

11. Adding English Site Resources to Baidu

In the Baidu Search Resource Platform, the Sitemap submission capability for the current site has always been unavailable, and the same was true for the original www site.

Therefore, for Baidu, I only handled resource addition and verification this time, and did not continue researching Sitemap submission.

I went to:

Plaintext
User Center
→ Site Management
→ Add Website

and added:

Plaintext
https://en.shuijingwanwq.com

For the site attribute, I selected:

Plaintext
Information Technology

Baidu provides file verification. The downloaded file looks like:

Plaintext
baidu_verify_codeva-xxxxxxxx.html

Since www and en share the same WordPress root directory, I only needed to upload the file to:

Plaintext
/data/wwwroot/www.shuijingwanwq.com/

ensuring it could be accessed via the English domain:

Plaintext
https://en.shuijingwanwq.com/baidu_verify_codeva-xxxxxxxx.html

The first verification failed, but the second attempt succeeded.

Based on the symptoms, it seemed more like a temporary network fluctuation when Baidu’s verification server accessed the English site on Cloudflare, rather than a file location error.

[Figure 9, Baidu English site file verification successful]
[Figure 9, Baidu English site file verification successful]

12. Sogou Verification Encounters Shared Directory File Conflict

Sogou also requires adding an English site resource and provides file verification.

However, Sogou’s verification filename is fixed as:

Plaintext
sogousiteverification.txt

The problem is:

The content of the Chinese site’s previous verification file was one set of old verification codes, while the content of the newly downloaded file with the same name for the English site was a different set of codes.

Because www and en share the same WordPress root directory:

Plaintext
/data/wwwroot/www.shuijingwanwq.com/

It is impossible to save two files with different contents under the same directory with the name:

Plaintext
sogousiteverification.txt

Overwriting it directly could affect the Chinese site’s original verification.

Therefore, I switched to Sogou’s HTML tag verification.

13. How to Use WPCode’s Site Wide Header

The verification tag format provided by Sogou looks like:

HTML
<meta name="sogou_site_verification" content="YOUR_SOGOU_VERIFICATION_CODE" />

To output it only on the English domain, I used the following in WPCode:

PHP
$host = strtolower(
    preg_replace(
        '/:\d+$/',
        '',
        $_SERVER['HTTP_HOST'] ?? ''
    )
);

if ( 'en.shuijingwanwq.com' !== $host ) {
    return;
}

echo '<meta name="sogou_site_verification" content="YOUR_SOGOU_VERIFICATION_CODE" />' . "\n";

The WPCode settings are:

Plaintext
Code type: PHP Snippet
Insert method: Auto Insert
Location: Site Wide Header

There is no need to write:

PHP
add_action( 'wp_head', ... );

here, because Site Wide Header itself means that WPCode will execute this code in the <head> area.

If the Location uses:

Plaintext
Frontend Only

then it is more appropriate to register it manually in the PHP code:

Plaintext
add_action( 'wp_head', ... );

You should choose one of these two approaches and avoid redundant nesting.

14. Why the Command Line Sees the Verification Tag, but the Browser Source Code Does Not

After saving the WPCode snippet, I first cleared the English domain’s object cache:

Bash
/root/bin/w3tc-flush-host-object-cache en.shuijingwanwq.com

I then used a curl request with a random query parameter to check:

Bash
for host in en.shuijingwanwq.com www.shuijingwanwq.com
do
    echo "================ $host ================"

    curl -sS -L --compressed \
        "https://$host/?_nocache=$(date +%s)" \
    | grep -oiE '<meta[^>]+name=["'\'']sogou_site_verification["'\''][^>]*>' \
    || echo "未找到搜狗验证标签"
done

The result was:

Plaintext
================ en.shuijingwanwq.com ================
&lt;meta name="sogou_site_verification" content="..." />

================ www.shuijingwanwq.com ================
Sogou verification tag not found

This indicated that the code logic was correct.

However, when viewing the standard homepage source code via:

Plaintext
view-source:https://en.shuijingwanwq.com/

the verification tag was still missing.

The reason was that the W3 Total Cache Page Cache for the English homepage was still serving an old version.

Object cache and page cache are two different caching systems. Clearing the Object Cache does not automatically delete the already generated static HTML Page Cache.

Therefore, it was necessary to clear the English domain’s page cache directory:

Bash
rm -rf /data/wwwroot/www.shuijingwanwq.com/wp-content/cache/page_enhanced/en.shuijingwanwq.com

Then, I purged the cache for this specific URL in Cloudflare:

Plaintext
https://en.shuijingwanwq.com/

After completing this, the Sogou verification tag finally appeared in the browser’s source code.

Once finished, the Sogou verification tag could finally be seen in the browser’s source code.

15. Why I Ultimately Gave Up on Sogou English Site Verification

Even though the correct verification tag was present in the page source code, Sogou continued to report verification failure.

I then went to Cloudflare:

Plaintext
Security
→ Analytics
→ Events

and filtered by hostname:

Plaintext
en.shuijingwanwq.com

During the time period when Sogou verification failed, no new blocks, challenges, or WAF events were found.

This indicates that:

  • The WPCode was in effect
  • The W3TC page cache had been updated
  • The Cloudflare page cache had been updated
  • Cloudflare security rules did not block the verification request
  • Sogou’s verification server might not have successfully accessed the English site

I could temporarily change the Cloudflare orange cloud to “DNS Only” and verify again, but considering that:

  • The traffic Sogou brings to the website has always been minimal
  • The English content is primarily aimed at Google and Bing users
  • Even if verification succeeded, subsequent Sogou crawls of the English subdomain might still be unstable
  • Adjusting the CDN architecture solely for Sogou offers very little return

I ultimately decided to abandon the Sogou English site resource.

The “Sogou English site HTML verification tag” code snippet in WPCode has been moved to the trash.

The verification meta temporarily left in the cache will not affect canonical tags, robots, Sitemaps, or other search engines, so I did not manually clear it again; I will just let the cache expire naturally.

[Figure 10, Sogou verification failed]
[Figure 10, Sogou verification failed]
[Figure 11, No corresponding blocking events in Cloudflare]
[Figure 11, No corresponding blocking events in Cloudflare]

16. Final Sitemap Structure

After completing all adjustments, the Sitemaps officially used by the website are:

Chinese Site

Plaintext
https://www.shuijingwanwq.com/sitemap_index.xml

English Site

Plaintext
https://en.shuijingwanwq.com/sitemap_index.xml

The final handling status across search engine platforms is as follows:

Search EngineChinese SiteEnglish SiteFinal Status
GoogleYoast Sitemap submittedYoast Sitemap submitted, and independent property addedSuccess
BingYoast Sitemap readYoast Sitemap submittedSuccess
360Switched to Yoast SitemapSubdomain added and submittedSuccess
BaiduExisting Chinese site resourceAdded and verifiedCurrently no Sitemap submission entry
SogouOriginal Chinese site retainedGave up adding English siteNo longer processing

17. Conclusions Drawn from This Troubleshooting

1. In Multiple Domain Mode, Cache Must Be Cleared by Host

In a Polylang multiple domain environment, clearing the cache only within the default domain context may fail to update the configuration and pages corresponding to the English domain.

2. Object Cache and Page Cache Should Not Be Confused

Clearing the object cache does not mean the static HTML pages have been updated.

When PHP code is in effect but the standard page source code still shows old content, you should continue checking:

Plaintext
W3 Total Cache Page Cache
Cloudflare Cache

3. Yoast’s Exclusion Logic Works by Term ID

If the database contains multiple tags with the same slug, determining whether a thin content tag has been excluded based solely on the URL may lead to misjudgments.

4. Sitemap Management Capabilities in Search Engine Dashboards Vary Greatly

Google allows explicit deletion of submission records.

Bing might display auto-discovered or historical Sitemaps for a long time, and the new interface does not necessarily provide a deletion function.

360 requires adding an independent site or subdomain first before you can submit the Sitemap for the corresponding Host.

The resource addition and verification methods for Baidu and Sogou are also significantly different from Google and Bing.

5. No Need to Modify the Website’s Basic Architecture for Low-Value Search Engines

If a search engine brings extremely low traffic, and its verification, crawling, and CDN access are chronically unstable, continuing to invest time may not be worthwhile.

SEO configuration also needs to consider return on investment, rather than striving for complete coverage on every platform.

18. Summary

This task seemed to merely involve changing the sitemap from:

Plaintext
/wp-sitemap.xml

to:

Plaintext
/sitemap_index.xml

In reality, it involved:

  • Migrating the English site from /en/ to an independent subdomain
  • Polylang multiple domain identification
  • Yoast Sitemap generation
  • Thin content tag noindex
  • Thin content tag Sitemap exclusion
  • Duplicate terms and duplicate slugs
  • W3TC Object Cache
  • W3TC Page Cache
  • Cloudflare XML and HTML caching
  • Google, Bing, 360, Baidu, and Sogou resource adjustments

Ultimately, the Chinese and English sites now have two distinct sets of Yoast Sitemaps:

Plaintext
https://www.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/sitemap_index.xml

The robots and Sitemap exclusion rules for thin content tags have also been verified using actual URLs.

At this point, the main Sitemap-related adjustments after enabling the independent en domain for the English site have been completed.

系列导航

需要长期技术维护或远程问题排查？

我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看：关于我 & 合作

微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章