Sitemap URL Not Allowed in Search Console: Causes and Fixes

What does the sitemap URL not allowed error mean?

The sitemap URL not allowed error means your sitemap file contains addresses that fall outside the file's scope. An address may sit on a different domain, use a different protocol, or live above the folder that holds the sitemap. Google reads the file but skips those lines.

Google's Search Console help page lists this problem as "URL not allowed" in the English interface. The Turkish and German interface wording may differ slightly, so if your screen shows a similar warning, treat it as the same issue.

One distinction matters here. This error is not about the file failing to open. Google opens the file, but some addresses inside it do not match the file's scope. If the file cannot be read at all, you have a different problem, which we cover in our guide to the Search Console sitemap could not fetch error. We will not repeat that here.

When does Search Console show this error?

The help page describes the cause in one sentence: the sitemap includes URLs at a higher level than the sitemap file, or on a different domain. In practice, we see four typical situations.

• The sitemap sits in a subfolder, but it lists addresses from the root or from sibling folders.
• Also, the domain in the addresses differs from the domain of the sitemap file.
• Sometimes the protocol does not match, with the file on one protocol and the addresses on the other.
• Finally, a plugin or CMS keeps writing the old domain after a migration.

All four share one trait: the start of each address does not match the place where the sitemap lives. Therefore half of the fix is a correct diagnosis. Once you find which line fails and why, the repair is usually short.

Why does the sitemap location define its scope?

Google's guide to building a sitemap says that unless you submit the sitemap through Search Console, it affects only the descendants of its parent directory. In other words, the file's address is the starting point of its scope.

For example, here is a scenario. Your sitemap lives at example.com/blog/sitemap.xml. Its natural scope is example.com/blog/ and everything below it. If you add example.com/about/ to that file, the address sits above the sitemap's folder.

For this reason, Google recommends keeping the sitemap at the site root. A file at the root covers every path on that host. As a result, you prevent most folder-related errors before they start.

We also want to be careful here. The help pages describe the Search Console submission case in different sentences, and we do not claim a firm exception. The safe route is simple: keep the file at the root and list only addresses that fall within its scope.

Which URL patterns trigger the sitemap URL not allowed error?

The examples on the Search Console help page fall into two groups: addresses above the file's level and addresses on a different domain. The table below combines those examples with our own scenarios. Assume the sitemap lives at https://www.example.com/sitemap.xml.

For example, the takeaway is simple: Google crawls addresses exactly as you write them. The guide also recommends fully qualified, absolute URLs. Therefore shortening an address or hoping Google will guess the rest only makes the problem bigger.

How do www, http and https differences cause this error?

A tiny difference at the start of an address means a separate resource to Google. In a browser, all variants may open the same page. However, the scope check looks at how the address is written.

A typical story goes like this. For example, for years the site ran on http. Then you installed SSL and moved to https. Redirects work, and you added the new property as https in Search Console. Still, the sitemap plugin may keep an old setting and write http into every address.

The same applies to www. For example, if you added a www property but your plugin generates addresses without www, most lines fall outside the scope. In addition, you usually see this across the whole file rather than on single pages.

First, pick one preferred address form. We call it the canonical form. Then keep it identical across your canonical tags, redirects and sitemap. For more on that topic, read our guide on how to detect and fix canonical issues in Search Console.

How do subdomains and folders change the sitemap scope?

A subdomain such as blog.example.com counts as a separate host from the main domain. So if you list blog.example.com addresses inside a sitemap on www.example.com, those lines can fail with the different domain reason.

Teams often make this mistake while growing, because the blog moves first. The blog moves to its own subdomain, but the plugin on the main site still adds every post to its own file. As a result, hundreds of foreign host lines pile up in the main file.

The fix is straightforward. First, publish a separate sitemap for each host at that host's root. The blog subdomain keeps its file at its own root, and the main site keeps its own. Then submit each file to its own property in Search Console.

In practice, the folder case works the same way. A file in the /en/ folder cannot carry pages from the /de/ folder. Multilingual sites fall into this trap often. Either use one index file at the root, or publish each language's file at the root.

Can a plugin generate the wrong domain after a migration?

Yes, and it is one of the most common causes we see. When you move from a staging site or an old domain, the database may still hold the old address. The plugin builds every URL from that saved value.

The symptoms are usually these:

• When you open the sitemap in a browser, the addresses start with an old or temporary domain.
• Or the file sits on the new domain, but every line points to another host.
• Then Search Console flags many lines for the same reason.

To fix it, first check the site address fields in your general site settings. Then look for a hard-coded domain in the plugin's own settings. Some plugins cache the old file, so you need to regenerate it after you correct the setting. If you use a caching plugin, clear that cache too.

If you plan a migration, put address, redirect and sitemap checks on the list from day one. Our website migration SEO checklist collects these steps in order.

What should you do in the first ten minutes?

First, do not panic. This error usually does not break your site; it only stops the affected lines from being processed. Still, a clear order saves time. Follow these steps.

1. Open the right property in Search Console and go to the sitemap report details for the failing file.
2. Copy the sample line from the error and read the start of the address carefully (protocol, www, host).
3. Check the property type you used: a domain property or a URL prefix property.
4. Open the sitemap in a browser and compare the first few addresses with the property.
5. Find the difference: http versus https, www, subdomain or folder.
6. Fix the source by updating the plugin setting or the file.
7. Resubmit the file and watch the report.

This order saves you from changing settings by guesswork. We cannot promise a result, but finding the cause is possible in most cases. The help page follows the same logic: addresses must match the domain and protocol level of the file.

How do you diagnose the source of the error?

In short, diagnosis means placing three things side by side: your Search Console property, the sitemap address and the addresses inside the file. All three should start with the same host and protocol.

First, start with the property type. A domain property, for instance, covers all subdomains and protocols. A URL prefix property covers only the exact prefix you typed. This difference can change what you see, because submitting an https file to an http prefix property is a separate problem.

Then inspect the file. For a small site, opening it in a browser is enough. For a large site, use the source view and check the first, middle and last lines. Plugins sometimes create several child files, so check each one separately.

Finally, test redirects. If an address in the file redirects elsewhere, the final address may fall outside the scope. You can check this quickly with our free redirect checker tool.

How do you fix the sitemap URL not allowed error in WordPress and plugins?

On most sites, an SEO plugin or the CMS itself generates the file. In that case, you do not edit the file by hand; you fix the source. Menu names change between versions, so we will not give exact button labels. You need to find the matching setting in your own panel.

Here is what to check:

• The site address and home address fields in your general settings.
• Any custom domain or base URL field in the plugin's sitemap settings.
• Also, whether your language plugin uses a separate domain or folder for each language.
• Then, whether the cache or CDN layer still serves an old file.
• Finally, whether the server redirects to your preferred www and https form.

After you correct these settings, open the sitemap again in a browser. Confirm that the addresses now use the new form. Only then go back to Search Console, because an old cached file brings back the same error.

If you build your own file by hand, our XML sitemap generator helps you write complete addresses.

Can one sitemap carry URLs for several sites?

Google's guide allows it. You can collect URLs from several sites in one file, even from different domains. However, conditions apply, and many people skip them and get the error.

The guide states that with robots.txt cross-submission, each site's robots.txt must point to its own sitemap file. In other words, you cannot pull another site's file into your scope just by declaring it. Each domain handles its ownership and its declaration on its own side.

For this reason, the idea of one file that covers everything is unnecessary for most small and mid-size sites. The simple and safe route is a separate file for each host. For multi-domain corporate setups, plan ownership checks and robots.txt declarations in advance.

One warning: do not add addresses of someone else's site to your file without permission, and do not submit their file under your account. Do not try to bypass the scope error for a property you do not own. Google can read that as an attempt to game its systems.

Does declaring the sitemap in robots.txt fix this error?

No, not by itself. Declaring the sitemap address in robots.txt helps Google find the file. But if the addresses inside the file do not match the scope, changing the declaration method does not remove the problem.

The guide says you can insert the sitemap line anywhere in robots.txt. Google finds it the next time it crawls the robots.txt file. You can list as many sitemaps as you need, each on its own line.

Instead of relying on it alone, use this method as a complement. A Search Console submission gives you status and error reports, while robots.txt gives you automatic discovery. Together they raise the chance of discovery, though they do not guarantee it.

Also keep robots.txt itself clean. A wrong blocking rule can stop Google from crawling the addresses in your sitemap. For the basics, read our robots.txt guide.

Should you choose a domain property or a URL prefix property?

Search Console offers two property types: a domain property and a URL prefix property. A domain property groups all protocols and subdomains of that domain. A URL prefix property covers only the exact prefix you enter.

This difference, in other words, makes diagnosis easier. For example, if you added only the https www prefix, you will not see data for other forms in that property. Then wrongly written addresses confuse both the report and the scope check.

Our advice is this: when you own the whole domain, add the domain property as well. Keep the specific prefix you work with as a separate property. That way you can compare the two views and see which form causes trouble.

A property type is not a magic fix. Whatever you choose, the addresses in the sitemap must match the file's host and protocol. The property type only makes diagnosis easier.

How do you set up sitemap scope on multilingual sites?

Multilingual sites usually use one of two layouts: language folders (such as /en/ and /de/) or a separate domain per language. Each layout has its own trap. Knowing them prevents the scope error early.

With folders, the safest route is to publish the sitemap at the root. A file inside one language folder cannot carry pages from sibling language folders. Therefore gather all languages in one root file, or in an index file that links from the root.

With separate domains, however, each domain publishes its own file at its own root. Do not write one domain's addresses into another domain's file. Country-specific domains show this mistake very often.

Language markers such as hreflang are a different topic. Here we only care about the scope of the file. Still, when you connect your language versions, make sure the addresses stay complete and consistent.

Example scenario: how do you fix the error after a migration?

The following is not a real client. It is an example scenario we built for illustration. A small company moves its site from a test address to the real domain. After the move, Search Console reports a scope error for most sitemap lines.

The diagnosis runs like this. First, you open the file and see that the addresses start with the test domain. Next, you check the general site address setting and find the test address still saved there. So the plugin builds addresses from the wrong source.

The repair takes three steps: switch the setting to the real domain, clear the cache and regenerate the file. Then you resubmit the file to the same property. After that, you watch the result for a few days.

Also, the error message does not name the root cause. It only reports a scope mismatch. To find the cause, you compare the addresses in the file with the property. Therefore the first job after every migration is to open the sitemap and read the start of a few addresses.

The lesson is clear: the problem usually does not live in the site itself but in a setting that nobody updated during the move. A checklist prepared before the move reduces this kind of oversight.

Do you need a sitemap index file on large sites?

As sites grow, it becomes common to produce several sitemap files. Collecting them in one index file makes management easier. However, the same scope logic applies to the index file.

As a rule, the index file sits at the root and links to child files. If a child file lives on another host or protocol, the scope error can return. Therefore write every link in the index file with the same host and protocol.

Check the limits on file size and count in the official guide. We do not quote numbers here because they can change. To simplify management, you can split sections by content type, such as pages, posts and products.

Checking every child file separately looks tedious. In practice, though, the faulty lines usually cluster in one child file. The Search Console report shows which file has the problem, so you can narrow the search.

Which mistakes should you avoid with this error?

Teams that see this error sometimes make wrong moves in a hurry. Here are the most common mistakes and better alternatives.

• Do not delete failing lines at random; find the cause first and fix the source.
• Decide on the right property once instead of adding a new one for every attempt.
• Never merge someone else's site into your file, because that bypasses the rules.
• Avoid opening a new account or faking an ownership check to hide the error.
• Skip hand edits that ignore the plugin, because the plugin regenerates the old error.

Haste lies behind all of these mistakes, so slow down. In fact, a sitemap URL not allowed warning usually comes from one setting difference. A calm diagnosis most often ends with a single fix.

How do you resubmit the sitemap after the fix?

After the fix, you resubmit the updated file to the same property in Search Console. First confirm that the live address shows the new content. Then submit it.

Follow this order:

1. Open the file in a browser and check the start of several addresses.
2. Clear the cache or CDN if you use one.
3. Select the right property in Search Console.
4. Resubmit the file's address in the sitemap section.
5. Watch the report status over the next few days.

However, we do not promise a timeline. Google's reprocessing depends on site size and crawl frequency, and the official sources give no fixed number of days. If the report does not change, verify again that the file really updated.

Also remove old, faulty files. A stale file left in the report can make a solved problem look open. Cleaning up needless entries keeps the report readable.

Does this error affect indexing and rankings?

It is not a direct ranking penalty, but there is more to say. The error only means that out-of-scope lines are not processed from the sitemap. Google can still find those pages through other paths, such as internal links.

Still, there is a side effect, because a sitemap is a hint. A sitemap is a hint that gives Google your list of pages. If the hint is incomplete, discovery of new and poorly linked pages can slow down. We cannot give a general figure for how long, since every site differs.

Therefore set your priorities this way. First, make sure your key pages appear in the sitemap with the right address. Then review your internal links and canonical setup. To investigate why pages stay out of the index, our guide on finding unindexed pages in Search Console can help.

In short, take the error seriously but do not exaggerate it. Publishing correct addresses is a cheap fix, and it reduces future discovery problems.

How is this error different from the sitemap could not fetch error?

The two errors work at different layers, so they need different fixes. Messages like "Couldn't fetch" concern access to the file. "URL not allowed" concerns the scope of the content after the file opens.

A file can carry both problems, so solve access first. Solve access first, then check scope. For the access side, use our sitemap could not fetch guide.

If you want the basics of sitemaps first, read what an XML sitemap is and how to create one.

Which checklist prevents the error from coming back?

The best way to prevent a repeat is a small routine after every change. Run it especially after migrations, SSL switches, new languages and new subdomains.

• Write down your single preferred address form (https and www choice).
• Publish the sitemap at the root and avoid subfolders.
• Confirm that addresses in the file are full and absolute.
• Define a separate file and property for each subdomain.
• Update hard-coded domains in plugin settings after a migration.
• Clear the cache and CDN.
• Match the sitemap line in robots.txt to the current address.

Because teams change, share this list with your team so that the person who makes a change and the person who reviews it read the same page. Also keep a permanent note about which property takes which file. That way, nobody recreates the error months later.

Our team follows one more habit, namely this: after a large change, open the sitemap report once. This few-minute check catches an error that could otherwise sit unnoticed for weeks.

When does expert help make sense?

On multilingual, multi-domain or large catalog setups, the cause can hide in several layers. The plugin, server redirects, the CDN and property setups all play a part at once. Changing settings one by one at that point can create new errors.

Talha Aslan and team have worked in the field since 2012, and we run this kind of diagnosis regularly. We do not guarantee outcomes. However, we can document the source of the problem and prepare a step-by-step fix plan.

If you want a broader roadmap, see our SEO consulting service. To learn the tool from scratch, start with what Google Search Console is and how to use it.

You may also like the other Search Console cases in this series: the Core Web Vitals not enough usage data message and the omitted entries very similar notice.

Note: this article gives general information. Official interface texts and menu names can change, so check current details on the Google Search Central and Search Console Help pages.