How to create a sitemap and submit it to Google - Zephyra Studio

A sitemap is a file listing the addresses you want Google to index. It does not affect ranking, but it helps new and updated content get discovered faster, especially when a site has many pages or few inbound links. Most sites do not need to write one by hand, because the platform or framework generates it. The job comes down to three moves: find the existing sitemap, check that it contains only addresses allowed to be indexed, and submit it in Google Search Console. The rest are details that decide whether Google uses the file at all.

What a sitemap is and what it is not

A sitemap is a file in XML format listing addresses. Each address can carry a last-modified date, which Google uses as a hint that content was refreshed. It is a hint, not a rule, and Google is free to ignore it.

A sitemap is not a ranking factor and will not repair weak pages. Its job is discovery: it shortens the path from publishing to the first crawl, which is felt most on new sites and on those with deep catalogues.

One file covers up to 50,000 addresses and 50 megabytes uncompressed. Larger sites use a sitemap index, a file that lists other sitemaps, usually split by content type: pages, articles, products, categories. This is different from the HTML version you sometimes see in a site footer, which is meant for people, not for search.

How to generate one

Building it by hand only makes sense for a small static site. Everywhere else it is generated, because addresses change more often than is reasonable to maintain manually.

• On WordPress: an SEO plugin generates it automatically, and recent WordPress versions offer their own sitemap too, usually at a wp-sitemap address
• On frameworks such as Next.js: add a route or a script that produces the file when the site is built
• If the site is static with a dozen pages, hand-writing works, but it must be extended with every new page
• Only canonical addresses allowed to be indexed belong in it, with no noindex pages, no redirects and no URLs carrying filter parameters
• The last-modified date should be real, because a falsely fresh date gains nothing and erodes trust in the file
• Finally, open the file in a browser and confirm it shows a list of addresses rather than a server error

Sitemaps on a multilingual site

On sites with several languages a sitemap has an extra role: it can carry the information about which pages are translations of the same page. That helps because search then knows those addresses belong to one topic rather than five different sites with similar content.

The simplest approach is a separate sitemap per language, with the list of versions for each address. That avoids the situation where every address sits in one list while the relationship between them is stated nowhere.

There is also a default version for the case when no language has been chosen, used by sites that select a language for the visitor based on location. It is listed once, for the group of translations, and should not be set as the main page.

On sites where content is translated later, only the language versions that actually exist belong in the sitemap. Adding a translation that has not been published yet makes Google record an error, and the submitted sitemap loses part of its value until the error is fixed.

If the sitemap is generated automatically, the check runs after every language change or new section. With a hand-written sitemap the check is mandatory on every edit, because forgetting to add a new address to the list is the easiest mistake to make.

• One sitemap per language, with the list of alternatives for each address
• A default version for the case where no language has been chosen
• The canonical address always in its own language version, never pointing at another country's language
• Each language version submitted in the tools for that language, because reports are kept separately
• Addresses that are only redirects between languages do not belong in the sitemap

How to submit it to Google

Submission happens in Search Console, in the sitemaps section. The site has to be verified first, because otherwise no processing report is available.

If you have a domain property, which covers both the www and non-www versions, submitting the sitemap once is enough. With several separate addresses, each one needs its own submission.

• Open the sitemaps section and enter the path rather than the full address, for example the one your system generates
• Wait a day or two and check the status: fetched successfully, or a fetch error
• Add a line to robots.txt pointing at the sitemap, which also tells other search engines where it is
• Submit it in Bing's tool as well if that traffic matters to you
• Do not submit the same sitemap repeatedly, because Google re-reads it on its own when content changes

Common problems and what they mean

A fetch error usually means one of three things: the address was typed wrongly, robots.txt blocks access to the file, or the server returns an error. The first check is whether the file opens in a browser without signing in.

The message that a sitemap contains addresses blocked by robots.txt is useful, because it reveals a mismatch: something you do not want crawled is still in the list. Such addresses are removed from generation rather than left in the file.

The most common misconception is that a sitemap solves indexation. If the content is thin or duplicates another site, a page can be discovered and still remain unindexed. Then the problem is the content, not the file. The indexation report in Search Console shows the reasons page by page, and technical SEO covers exactly those cases, from redirects to canonical addresses.

Related guide

Source

Key takeaways

• A sitemap helps discovery rather than ranking, and benefits new sites and large catalogues most.
• Only canonical addresses allowed to be indexed belong in it.
• One file covers up to 50,000 addresses; larger sites use a sitemap index.
• Submission happens in Search Console, and a robots.txt line also tells other search engines.
• When a page stays unindexed, the cause is usually the content, not the sitemap.

Conclusion

A sitemap is one of the rare technical jobs that takes half an hour and is then forgotten, with an occasional status check. If Search Console reports an error, or pages stay unindexed, looking at the indexation report is more useful than resubmitting the same file. On new sites we handle this together with setting up analytics and Search Console, so the first results are not waited on for weeks for no reason.