Search Console sitemap couldn't fetch or has errors: fixes for Mac users in 2026

What the Sitemaps report tells you

Open Search Console, pick your property, then go to Indexing > Sitemaps in the left sidebar. You will see each sitemap Google knows about. Every row shows a status, a count of discovered URLs and a Last read date. The status tells you which kind of problem you have.

Google uses three statuses. Success means Google fetched the file and read it without errors. Has errors means Google fetched it but found problems inside. Couldn't fetch means Google could not retrieve the file at all. Each status points to a different fix, so read it before you touch anything.

• Success: fetched and read with no errors. It does not prove your pages are indexed.
• Has errors: fetched, but some entries failed. URLs that parsed cleanly still go into the crawl queue.
• Couldn't fetch: Google could not get the file. Check the address, robots.txt and the server first.

Read Success carefully. It only tells you the file parsed. The pages in it still have to be found, crawled and indexed. Google also calls a submitted sitemap merely a hint, so it does not guarantee the file is downloaded or used.

What a sitemap error costs you

Think about the cost in three buckets. There is your time, the pages that wait to be found, and the goodwill of the developers you ask for help. Each one shows up differently. The sections below show where the numbers are real and where they are not.

Why it happens: the usual causes

Most sitemap errors come from a short list of problems. Google groups them into URL problems, domain or www mismatches, file size limits, syntax errors and download errors. Match what you see in the report to the table below, then work through that cause.

The vendor study also looked at which flaws show up most. Redirecting URLs topped the list. It found them on 92 of the 400 sites with sitemaps, which is 23.0%. A redirect means the sitemap lists one address, and the server sends visitors to another. A sitemap should list the final address.

The second most common flaw was an identical lastmod date across a whole file. The study found it on 88 sites, or 22.0%. If every page shows the same modification date, the date stops being a useful signal. Use the date each page actually changed.

Download failures have their own causes. Google lists a sitemap blocked by robots.txt, an unresolved manual action, a wrong sitemap address that returns HTTP 404, temporary server problems and low crawl demand. Low crawl demand means Google has little reason to fetch the file often. Check that cause last, after the simple ones are ruled out.

Fixes you can do without buying anything

Fix a Couldn't fetch status

Start in Chrome. Click the address bar or press ⌘L, type your domain, then add /sitemap.xml or the address your sitemap uses. If the page loads and shows XML, the file exists. If you see a 404 page, the address is wrong or the file moved.

1. Open the sitemap address in Chrome and confirm it loads as XML, not an error page.
2. Open your domain with /robots.txt and look for a Disallow rule that covers the sitemap path.
3. If the file moved, update the address in your CMS or SEO plugin so it stops returning 404.
4. Run a live test on the sitemap address in the URL Inspection box until Page fetch reads Successful.
5. Go to Indexing > Sitemaps, paste the address into Add a new sitemap, then click Submit.

If the page loads in your browser but Search Console still says it couldn't fetch, suspect the server. Temporary server problems can clear on their own. Ask your host or developer for server logs from the times Google tried. Then resubmit once the server responds cleanly.

Fix a Has errors status

Has errors means the file reached Google. Open it in Chrome and press ⌘F, then search for the ampersand. A raw ampersand breaks the syntax. Every ampersand inside a URL has to become the escaped form. Other special characters need escaping too.

Check size and count next. Google's limit is 50MB uncompressed and 50,000 URLs for each sitemap. Larger sites split the list into several sitemaps and reference them from a sitemap index. A sitemap index can reference up to 50,000 sitemaps, and it must not exceed 50MB either.

Check the domain last. If your property is https://www.example.com, every URL in the file must use that host. A mix of www and non-www addresses causes a mismatch error. Pick one version, match the property to it, and update the sitemap.

Worked example: a sitemap that couldn't be fetched after a site move

Say a CMS update moved your sitemap from /sitemap.xml to /sitemap_index.xml. Search Console still lists the old address, and the Sitemaps report says Couldn't fetch. Open the old address in Chrome and you see a 404 page. Open the new address and you see XML.

Submit the new address in Indexing > Sitemaps. Then remove the old entry only after the new one reads Success. Removing the old entry does not erase the URLs Google already knows, so cleaning up does not cost you pages.

Check the new row a few days later. The Last read date should move forward. If it does not, go back and check robots.txt, the server and the file contents, in that order.

Submitting a sitemap the right way

Submitting is the easy step, and it goes wrong when the file is not ready. Google's order is short. Confirm the property is yours, post the file, test it, then submit it. Skipping the test means you find out about problems later, inside the report.

1. Confirm you have owner permission on the property in Search Console.
2. Post the sitemap file, ideally at the root of your domain.
3. Test it with URL Inspection until Page fetch reads Successful.
4. Open Indexing > Sitemaps, paste the URL into Add a new sitemap, then click Submit.

You can also point search engines to a sitemap with a Sitemap line in robots.txt, or by pinging. The sitemaps.org FAQ lists those options. For Google, the Sitemaps report is still the place to see the status and the errors in one spot.

Where Screaming Frog fits, and what it costs

If the list of URLs is the problem, a crawler checks each address in bulk. Screaming Frog SEO Spider runs on macOS, with Apple silicon and Intel builds. Its free version is capped at 500 URLs, which covers a small sitemap or a sample of a larger one.

A single paid licence is listed at €245 per year on the vendor's pricing page, with volume discounts for larger teams. The page shows euros only, and prices can change. Check the pricing page for the current figure in your currency.

Start with the free version. Move to a paid licence only when the free cap blocks the check you need. A sample check can show whether a problem is widespread or a one-off.

Where Lazur helps, and where it does not

Lazur listens and looks at your screen only while you hold the shortcut. Hold ⌥ ⌘ while the Sitemaps report is open and ask what the status means. Lazur answers out loud and can circle the Sitemaps item or the Add a new sitemap box.

Lazur does not fix the sitemap. It does not edit files, click Submit or change server settings. The fixes above still take your hands, and sometimes your developer's time when the problem sits on the server.

Where it helps is the routine around the fix. Ask Lazur to walk you through resubmitting, one click at a time, and it waits for each click. Ask it to draft the ticket with the status and the URL. Hold fn to dictate the ticket text at your cursor in any app.

Mistakes people make with sitemap errors

• Deleting the sitemap to clear the error. Google keeps the URLs it already knows, so change the file and resubmit.
• Treating Success as proof of indexing. Success only means the file read cleanly.
• Editing a generated sitemap by hand. The next rebuild overwrites the change, so fix the setting that makes the file.
• Ignoring a blank Last read date. A blank date means Google has no successful fetch on record.
• Fixing one sitemap and skipping the rest. A large site can have several sitemaps, so check every row.
• Assuming Bing works the same way. This guide did not verify Bing's steps, so check Bing Webmaster Tools' own help.

A weekly routine for sitemap checks

Check the Sitemaps report once a week, and after any site move, redesign or CMS update. Keep a short log in Google Sheets with the date, the status, the Last read date and what you changed. A log turns a vague problem into a list you can hand to a developer.

If the log grows, filter it by status to see which problems repeat. A repeat often points to one template or one plugin. Fix that source once instead of chasing the same entry again.

Next steps

Read the status first, then open the file in Chrome. Fix the smallest cause that matches the status. Resubmit, then check the Last read date in a few days. For help with ticket wording or the steps in the report, ask Lazur, or download it and try it on your Mac.