[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1791688379063.jpg (295.63 KB, 1024x1024, img_1791688368256_ur8qvmtu.jpg)ImgOps Exif Google Yandex

ebcb5 No.2316

stuck in this nightmare with an nginx config change for a client. everything looks fine in the browser but logs show a redirect loop specifically for the xml files. tried stripping the trailing slash rule but it didn't fix anything.

location ~* \.xml$ {rewrite ^(.*)/$ $1 permanent;}


it's acting like the sitemap is hitting a different block entirely.
>the crawler just sees a 301 loop and gives up. checked the upstream headers and they look clean, so i'm losing my mind. tried testing with curl but even that returns the same mess. turns out the legacy regex in the main server block is catching them too.

ebcb5 No.2332

>>2316
>checked the upstream headers and they look clean, so i'm losing my mind.

if curl is hitting a loop then your headers aren't clean at all. you've got an infinite chain of 301s. check if that legacy regex is actually accidentally stripping something else from the path before it even hits your xml block.

ebcb5 No.2334

>>2316
>the legacy regex in the main server block is catching them too.

Ran into this exact thing on a migration for a retail client last year. The main block was doing some weird path normalization that basically stripped the extension before your specific xml block could even see the full filename. Check if that legacy rule is mutating the URI string.



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]