Support

Neither your sitemap is empty, nor its XSLT file is blocked.

Your sitemap is https://animalkingdom.co.za/sitemap.xml which is a 990 byte file:

$ wget "https://animalkingdom.co.za/sitemap.xml" -O sitemap.xml && ls -lh sitemap.xml
--2023-07-31 17:01:05--  https://animalkingdom.co.za/sitemap.xml
Resolving animalkingdom.co.za (animalkingdom.co.za)... 41.203.18.71
Connecting to animalkingdom.co.za (animalkingdom.co.za)|41.203.18.71|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/xml]
Saving to: ‘sitemap.xml’

sitemap.xml                     [ <=>                                      ]     990  --.-KB/s    in 0s      

2023-07-31 17:01:09 (148 MB/s) - ‘sitemap.xml’ saved [990]

-rw-rw-r-- 1 nicholas nicholas 990 Ιουλ 31 17:01 sitemap.xml

This is what the search engines see. They do not care about the XSLT which transforms the sitemap to human-readable HTML. Search engines only care about the machine-readable XML.

Your XSLT file is actually a virtual URL, https://animalkingdom.co.za/default.xsl?sitemap=root, as I can see in the XML file itself. This URL loads just fine, a 13117 byte file:

$ wget "https://animalkingdom.co.za/default.xsl?sitemap=root" -O test.xsl && ls -lh test.xsl
--2023-07-31 17:03:23--  https://animalkingdom.co.za/default.xsl?sitemap=root
Resolving animalkingdom.co.za (animalkingdom.co.za)... 41.203.18.71
Connecting to animalkingdom.co.za (animalkingdom.co.za)|41.203.18.71|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/xml]
Saving to: ‘test.xsl’

test.xsl                        [ <=>                                      ]  12,81K  --.-KB/s    in 0,02s   

2023-07-31 17:03:26 (561 KB/s) - ‘test.xsl’ saved [13117]

-rw-rw-r-- 1 nicholas nicholas 13K Ιουλ 31 17:03 test.xsl

I don't know why the output is empty. I suspect there's a problem with the XSLT file. I do not have an XSLT 2.0 CLI processor here to see if this is the case. What I could test, did test, and shared the results with is access to the web resources. This is the only thing Admin Tools could block and it does not block it in your case.

The error you get in Google tells you what is going on. Line 5 of your XML sitemap fetched over HTTPS reads:

<sitemapindex xmlns="https://www.sitemaps.org/schemas/sitemap/0.9">

The xmlns attribute is the namespace referenced in the error message.

Reading https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps, the correct namespace is http://www.sitemaps.org/schemas/sitemap/0.9.

Note that the namespace looks like a URL but it is not. It is a URI and it must be included verbatim. This means that Its scheme MUST ALWAYS be http, never https. There is no such XML namespace as https://www.sitemaps.org/schemas/sitemap/0.9.

If you are using “Convert all links to HTTPS when site is accessed over SSL” in Admin Tools, set this to No.

If this didn't help, check if you have any other plugin which may be doing this conversion.

If there is no other plugin, contact the sitemap plugin's author.

As to why Google shows the same error in both cases, I suspect it's because it tries to upgrade the connection to HTTPS anyway. I have not used their tools in a very long time, so I cannot tell you if they definitely do that. It would explain, though, why they complain about line 5 even when using plain HTTP for your sitemap URL (since your plain HTTP sitemap.xml has the correct namespace).

Regarding accessing the XML sitemaps from your browser, please see the previous reply.

The contents of the xmlns attribute must always use http, not https. This has nothing to do with the URL you use in Google Webmaster Tools. The URL you use in Google Webmaster Tools can of course be https.

When you enable the “Convert all links to HTTPS when site is accessed over SSL” in Admin Tools it does exactly that: it converts all instances of http:// to https:// in the output of your site. Since the sitemap plugin does not create a real sitemap file (it's a virtual URL, i.e. accessing it runs WordPress) it goes through that Admin Tools feature. This feature converts the http:// to https:// even though in the case of this xmlns attribute it shouldn't. There is nothing we can do because WordPress, unlike other CMS like Joomla, does NOT let the developer of a plugin (e.g. the developer of a sitemap plugin) specify the content type of the request in a way that can be communicated to other plugins (such as Admin Tools). As far as WordPress is concerned, all generated pages are HTML. The only thing we could do on our end, in a future version of Admin Tools, is check if the URL has an extension such as .xml and refrain from running this feature.

As for what the sitemap plugin does, whether Google understands the content it generates, and how it takes for Google to refresh the list of the pages it is going to index: ask the developer of the sitemap plugin. We cannot possibly do support for someone else's plugin. Based on what I know from when I last used Google's Webmaster Tools it may take up to 3 months for the sitemap to have any effect, completely depending on how important your site is to Google.