• Resolved Matt Biscay

    (@skyminds)


    Hello Sybre,

    I’m having issues with sitemap.xml : it returns a 404 page since TSF was upgraded to 4.0

    I’m using NginX with the correct directive:
    `location / {
    try_files $uri $uri/ /index.php?$args;
    }`

    I used to have a redirect rule to /?the_seo_framework_sitemap=xml but I removed it, cleared all cache. I read the changelog and the docs. I don’t have the Yoast rules anywhere.

    Domain to test: kriyayoga.fr

    Thank you,
    Matt

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Sybre Waaijer

    (@cybr)

    Hi Matt,

    There is good news: The XSL (sitemap stylesheet) endpoint does work: /sitemap.xsl

    I tested the translation-plugin friendly endpoint: /sitemap.xml-YouCanAddAnythingHere, and that seems to load the sitemap. This is indicating that your web server is working (almost) as intended ??

    Now, any request ending with .xml will lead to the generic NGINX-404 page. So, see if there’s a directive sending .xml requests to 404, and remove that. Good luck!

    Thread Starter Matt Biscay

    (@skyminds)

    Hello Sybre,

    Thank you for your reply, I investigated but the only directive that target xml files is for cache exclusion.

    Another sitemap exists on the server as a physical file and is being served:
    `/sitemap-index-image.xml’
    so I’m thinking it has something to do with a rewrite rule.

    Under TSF v3, I used to have this line in my NginX config:
    rewrite ^/sitemap.xml$ "/?the_seo_framework_sitemap=xml" permanent;
    but I removed it as under TSF4, it was displaying the homepage instead of the feed.

    The URL/redirect above must have changed with TSF4 perhaps?

    Thank you,
    Matt

    Plugin Author Sybre Waaijer

    (@cybr)

    Hi Matt,

    In TSF 4.0, we completely removed our dependency on the WordPress rewrite system. I wrote about that in the release notes, and before the release I announced the reason: Yoast spread misinformation about the sitemap.

    With that, the rewrite rule you have can no longer work; as it no longer relies on a query parameter (unless you use plain permalinks, which you shouldn’t use).

    I want to try to visualize my findings.

    These endpoints lead to a WordPress 404 page:

    /404.jpg
    /404.png
    /404.404
    /404.xsl
    /404.ico
    
    etc...
    

    And these will lead to an NGINX 404 page:

    /404.xml
    /anything/404.xml
    /anything/404/really-anything.xml

    Note that the last group all ends with .xml. This is where the issue lies, and it is why I asked you to investigate on what’s causing that.

    Now, we set the content-type to text/xml whenever the sitemap is requested. So, using .xml isn’t required for displaying a valid sitemap. With that, you may want to use a different sitemap endpoint instead until you can find the cause. How does /sitemap.xmlalt sound? ?? It’s valid, although non-standard.

    Maybe this NGINX rule will do the trick for you:

    rewrite ^/sitemap.xml$ /sitemap.xmlalt permanent;
    

    Cheers!

    P.S. xmla is another standard, which is why I’m not suggesting using it.

    Hello! Any progress on this?
    All my sites on nginx with tsf 4.0 update got broken sitemap, and i can’t find a solution for this ??

    Found a problem in my nginx conf – i’ve had such block

    	# Don't cache appcache, document html and data.
    		location ~* \.(?:manifest|appcache|html?|xml)$ {
    		expires -1;
    		}
    

    just deleted it, and everything is okay! thank you for you hack with xmlalt

    Thread Starter Matt Biscay

    (@skyminds)

    Hello Sybre,

    Thank you ever so much for your patience and the time you took to explain things. I really appreciate it!

    denisyan: thank you too, your message made me look into another config file. I had the same block as yours and we need to take out the xml part.

    Thanks again,
    Matt

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Sitemap.xml returns 404’ is closed to new replies.