WP开发教程 WordPress导师在线教程
When the website was first submitted, Google indexing was very fast, reaching 27 pages in just one week. However, after two weeks, the indexing began to drop drastically. I originally built a multilingual site using subdomains, for example, es.example.com. But all AI tools suggested that this is not good for the website’s own authority because it disperses weight; in Google’s eyes, es.example.com is a single website rather than part of example.com. Therefore, in the Polylang language settings, I changed it to the subdirectory format like example.com/es so that the site’s authority would not be dispersed. However, using “The SEO Framework” with this setup prevented the generation of a complete sitemap. I later tried multiple sitemap tools, but none could generate a professional sitemap, or the generated sitemaps showed 0 crawls after being submitted to Google. Later, I used the default WordPress sitemap to submit to Google, and it now shows that Google has discovered 5,500 URLs, but after two weeks, they are still not indexed. Even after resubmitting the links, not a single one has been indexed. So today I resubmitted the Products URLs to Google, and the page indicated that it could not be crawled, showing a redirection error. I figured redirection errors are usually caused by the .htaccess file. I entered the URL into https://httpstatus.io/, and the status indeed showed 403, so I asked Claude:
As a Google SEO expert and WordPress expert, will this .htaccess file cause website redirection errors? When performing URL inspection and requesting indexing in Google Search Console, it shows a redirection error and cannot be crawled: # SGS XMLRPC Disable Service <Files xmlrpc.php> order deny,allow deny from all </Files> # SGS XMLRPC Disable Service END # BEGIN WordPress # The directives (lines) between “BEGIN WordPress” and “END WordPress” are # dynamically generated, and should only be modified via WordPress filters. # Any changes to the directives between these markers will be overwritten. <IfModule mod_rewrite.c> RewriteEngine On RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index.php$ – [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress # SGO Unset Vary Header unset Vary # SGO Unset Vary END
Claude’s Answer:
I will carefully analyze this .htaccess file to find the reasons that might cause redirection errors in Google Search Console.
Problem Diagnosis
This file itself does not contain any 301/302 redirect rules, so .htaccess itself is not the direct cause. However, there are several potential issues:
⚠️ Issue 1: Header unset Vary may interfere with crawlers
Header unset Vary
This line removes all Vary response headers. Googlebot relies on Vary: User-Agent to distinguish between mobile and desktop content. Removing it may lead to:
- Caching layers (CDN/Server) returning an incorrect cached version to Googlebot
- Triggering unexpected redirects under certain server configurations
⚠️ Issue 2: Lack of forced HTTPS redirect rules
If the website has both http:// and https:// versions but no unified redirection rules in .htaccess, it may lead to:
- Google being redirected by the server layer (not .htaccess) when crawling the http version
- Redirect chains that are too long (http → https → www → final URL)
⚠️ Issue 3: mod_rewrite configuration needs confirmation
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
This line sets environment variables and is usually harmless, but if the server has multiple levels of .htaccess (e.g., in subdirectories), it may cause rule conflicts.
Troubleshooting Steps
Step 1: Confirm the actual redirect chain
Run in the terminal (replace with your URL):
curl -I -L –max-redirs 10 -v https://yoursite.com/target-page
Or use online tools like httpstatus.io to view the full redirect chain.
Step 2: Check server-level redirects
Redirects may come from:
- WordPress plugins (Rank Math / Yoast / Redirection)
- Server control panels (cPanel / Nginx configuration)
- CDN settings (Cloudflare Page Rules)
Step 3: Check specific URLs shown in GSC
In Search Console → URL Inspection → View the target URL the “Redirect” points to, to determine which step failed.
Recommended Fix Solution
If you need to add standardized HTTPS + www unified redirection, the full structure of .htaccess should be:
# SGS XMLRPC Disable Service
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
# SGS XMLRPC Disable Service END
# BEGIN Force HTTPS (Add as needed)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END Force HTTPS
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
# SGO Unset Vary
# Header unset Vary ← It is recommended to comment out this line and observe if it affects GSC crawling
# SGO Unset Vary END
Conclusion
| Check Item | Risk Level | Recommendation |
| Header unset Vary | 🟡 Medium | Comment out and test first |
| Missing HTTPS redirect rules | 🟠 High | Confirm if handled by other layers |
| WordPress rewrite rules | 🟢 Low | Standard configuration, no issue |
| xmlrpc.php blocked | 🟢 None | Normal security configuration |
The most likely reason is that the redirection is occurring at the server layer or CDN layer rather than this .htaccess. It is recommended to use the curl -IL command first to see the full redirect chain before locating the root cause. Do you need me to help you analyze further?
I re-confirmed the forced HTTPS and the WordPress URLs. After ensuring they were unified, I modified the .htaccess file using the version fixed by Claude. Then I submitted it to Google, and the prompts for “unable to navigate” and redirection errors disappeared. The tool also showed a status of 200, and 403 no longer appeared.
