Back to the blog
WebsitePublished 4 min read

Google Search Console for Business Owners: Sitemaps and Indexing

Search Console shows what Google actually sees of your website. Start with verification and a sitemap, then learn to read the indexing and performance reports.

A computer screen showing an analytics dashboard with a bar chart
Photo by 1981 Digital on Unsplash

A finished website doesn't automatically show up on Google. Google has to find your pages, read them, and decide whether to index them. Google Search Console is Google's free tool for seeing that process from your side: which pages are indexed, which aren't and why, and which searches bring visitors in. This guide covers the basics, including our own sitemap showing "Couldn't fetch" on a new domain.

Step 1: verify a property

A property is the website you want to monitor. There are two kinds:

  • A Domain property covers the whole domain, including http, https, and subdomains such as www. You verify it with a TXT record in your DNS settings, where you bought the domain or at a provider such as Cloudflare.
  • A URL-prefix property only covers addresses starting with exactly what you enter, such as https://www.example.com/. You can verify it with an HTML file, a meta tag, or Google Analytics.

Step 2: submit a sitemap

A sitemap is a file listing your important pages, usually at /sitemap.xml. Open the Sitemaps menu, enter its address, and submit. Search Console then shows one of these statuses (wording varies slightly by language):

  • Success: the sitemap was read, with the number of addresses found.
  • Has errors: it was read, but parts have problems, such as invalid addresses.
  • Couldn't fetch: Google hasn't managed to download the sitemap file at all.

A sitemap helps Google find pages; it doesn't guarantee they get indexed.

Our story: "Couldn't fetch" on a new domain

When we set up the Lumekara site on the new domain lumekara.dev, we submitted the sitemap right after the property was verified. Search Console immediately showed "Couldn't fetch". Yet when we tested it ourselves, the sitemap was reachable as normal: the server answered HTTP 200, the content type was application/xml, and it listed 58 addresses.

This status often appears temporarily on a new property, because Google hasn't actually fetched the file yet. Don't panic or change lots of things at once, but don't just wait either. Rule out the real causes so you know the problem isn't on your side.

Checklist when a sitemap can't be fetched

  1. Open the sitemap in a private browser window. It should show a list of addresses, not an error or login page.
  2. Make sure the latest version is deployed. A sitemap on your developer's computer may not be on the server yet.
  3. Make sure the domain is connected to the hosting, https works, and the sitemap uses the property's domain.
  4. Check security and firewall rules, for example in Cloudflare. A strict anti-bot challenge can block Googlebot too.
  5. Check robots.txt. Make sure it doesn't block the sitemap or important pages.
  6. Check you're in the right property. A sitemap at https://www.example.com doesn't belong in a URL-prefix property for https://example.com.
  7. Test one page with URL Inspection. If everything above is fine, give it a few days, then resubmit the sitemap.

URL Inspection and the live test

URL Inspection checks one address. The first result shows Google's latest data: whether the page is on Google, when it was last crawled, and which canonical address Google chose. Test live URL checks the page as it is now, which is useful after a fix. If it looks good, you can request indexing; that queues the page but doesn't guarantee indexing.

The pages report: indexed and not indexed

The page indexing report splits addresses into indexed and not indexed. Not indexed isn't always a problem, as long as the reason makes sense. Common reasons:

  • Crawled, currently not indexed: read but not added yet. Common for new or thin pages.
  • Discovered, currently not indexed: known but not read yet.
  • Alternate page with proper canonical tag: normal, since it points to the main version.
  • Excluded by noindex or blocked by robots.txt: fine if intentional, harmful on pages you want found.
  • Not found (404) or page with redirect: check for old links to fix.

The performance report: queries, clicks, and impressions

Queries are what people type into Google. Impressions count how often your pages appeared in results. Clicks count how often people opened them. The most useful pattern is a query with many impressions but few clicks: usually the page's title or description needs to be clearer. This data typically lags a few days.

robots.txt and canonical

  • robots.txt tells search engines which parts not to crawl. It doesn't hide pages from Google; use noindex for that. List your sitemap in it too.
  • Canonical points to the main version when several addresses have similar content. Google treats it as a strong hint, not a command.

At Numekara, the education business we run, the sitemap lists Indonesian and English versions of its pages with hreflang markers. Its blog articles are Indonesian only, so their canonical always points to the Indonesian version. When Numekara moved domains, we verified the new property, submitted the sitemap, confirmed with the live test that the site was available to Google, and filed a change of address from the old domain.

Search Console won't raise your ranking. It shows you what Google actually sees.