【Search Console】Sitemap and indexing traps on first setup

Notes on where I got stuck choosing a property type and filling in the sitemap field when I connected a new site to Search Console

When you open Google Search Console on a site you just launched, the first question is the property type. Domain or URL prefix. Which one to pick, and where to put the sitemap after that, is not obvious from the UI labels alone.

You put an article URL in the sitemap field and get “Sitemap is HTML,” or a site: search shows only the homepage and none of the inner pages yet. Before you treat that as a ranking problem, there is a stage where the pages are simply not indexed.

I look at what the property can see first, then what goes in the sitemap field, then where to put a page when I want it indexed sooner.

Terms

Property

The container for a site when you register it in Search Console. The name you switch in the top-left is the property.

Clicks and sitemap status are counted only for URLs that belong to the property you have open. To look at another domain, open another property.

Domain / URL prefix

The two property types. Domain is all of example.com. URL prefix is only pages that start with https://example.com/. The difference is not SEO strength. It is what the admin UI can see.

Sitemap

A file that lists URLs on the site. A common location is https://example.com/sitemap.xml. In Search Console’s sitemap field, you specify this one file.

URL Inspection

A screen that shows what Google sees for a specific URL. From here you can “Request indexing.” It is a different menu from the sitemap field.

Domain vs. URL prefix

A property is the range of URLs you treat as one site. This is where people get stuck first.

Domain property

The registration example is example.com. Do not add https:// or www.

The scope is the whole domain. https:// and http://, with or without www, and other subdomains all land in the same property.

The only verification method is a DNS TXT record. You do not need to touch the site’s HTML. You do need permission to edit the domain’s DNS.

Add a property in Search Console and choose Domain
Enter example.com. Do not add https:// or www
Copy the TXT value that appears. The shape is google-site-verification=...
Add a TXT record in the DNS admin. Host is @, or empty
Wait for it to propagate, then press Verify in Search Console

Propagation can finish in a few minutes, or take a few hours. If it fails right away, check the record value, wait, and verify again.

URL prefix property

The registration example is https://example.com/. Only pages that start with that URL are in scope.

Included: /, /articles/..., /docs/..., and everything else under that prefix. Not included: the http:// version, the www version, and other subdomains.

Verification methods include uploading an HTML file, a meta tag, Google Analytics, Google Tag Manager, and so on. You can proceed without touching DNS.

If I draw the visible range as a tree, it splits like this.

Domain: example.com
└─ https://example.com/
   ├─ /
   ├─ /articles/...
   ├─ /docs/...
   └─ ...
└─ https://www.example.com/...   ← this is the same property too
└─ http://example.com/...      ← this is the same property too

Figure: Domain also puts https / www / http variants in the same property.

URL prefix: https://example.com/
└─ /
   ├─ /articles/...
   ├─ /docs/...
   └─ ...
   (http and www versions are a different property)

Figure: URL prefix is only pages that start with the URL you specified.

A common misunderstanding is “with URL prefix, nothing but the homepage gets indexed.” That is not true. Prefix does not mean “homepage only.” It is everything under https://example.com/.

The Domain vs. URL prefix difference is not about who wins in search. If production is only https://example.com, URL prefix is enough. If you later want to see www or other subdomains too, add a Domain property.

What “only the homepage shows up in search” means

With site:example.com, you can get a state where the homepage is listed and articles are not yet.

This is a two-stage story.

sequenceDiagram
    participant Page as Page
    participant Search as Google Search
    participant User as Searcher

    Search->>Page: ① Index it<br/>eligible for search results
    User->>Search: ② Search
    Search-->>User: ③ Ranking<br/>which position

Figure: Listing comes first, then ranking becomes the question.

What is missing now is ①. Before “SEO is weak,” the pages are not in the results at all.

Two ways to deal with it:

Wait for crawl — Google follows the sitemap and internal links on its own
Nudge it yourself — use URL Inspection and “Request indexing”

If you are not in a hurry, waiting is enough. If you want something listed sooner, request just a few important pages. You do not need to submit every URL one by one.

The sitemap field takes a file only

Search Console’s “Sitemaps” is not where you register page URLs. It is where you specify one sitemap file.

The correct submission is only this:

sitemap.xml

You do not need https:// or a leading /. If the property is https://example.com/, Search Console fetches https://example.com/sitemap.xml.

If you get it wrong, you see messages like these:

“Sitemap is HTML” — it read an HTML page (including 404s)
“Couldn’t fetch” — a URL that does not exist, or a bad format

If I split the actual responses, they look like this:

Submission	Fetched URL	Result
`sitemap.xml`	`/sitemap.xml`	XML. This is the correct one
`sitemap`	`/sitemap`	HTML 404 in most cases
`docs`	`/docs`	A normal HTML page

【Sitemap submit】When it is correct

Search Console: “I’ll fetch sitemap.xml. If it starts with <?xml, I’ll read it as a URL list.”

【Sitemap submit】When you entered docs

Search Console: “I fetched it and got an HTML page back. That is not a sitemap.”

Even if /sitemap.xml on the site is valid XML, putting a different string in the field makes Search Console look there instead. The only issue is that it is looking at the wrong place.

The correct state is “Success” / “Sitemap processed successfully.” It means Google could read the file and recognized the URL list inside. It does not mean every URL is in search. You have handed over the candidate list.

Pages you want listed sooner go in URL Inspection

What you want to do changes the place.

What you want	Where	Example input
Tell it about every page at once	Sitemaps	`sitemap.xml`
List a specific page sooner	URL Inspection	`https://example.com/articles/hello`

【Tell it about everything at once】

Me: “Here is the URL list. Come back and check it periodically.”

Search Console: “Got sitemap.xml. I have the candidates.”

【Want one page listed sooner】

Me: “Please look at this page first. https://example.com/articles/hello”

Search Console: “I’ll inspect the URL, then accept an indexing request.”

Do not put an article URL in the sitemap field. Individual notices go through URL Inspection.

Do not redo this on every update

Submitting the sitemap once at the start is enough. When you add an article and deploy to production, sitemap.xml updates too. Google refetches it periodically.

Index requests feel like this:

Case	Needed?
New site, first few pages	Faster if you do it
One new article	Optional
Light edit to an existing article	Usually no
Large title change	Optional

Day to day, writing and deploying is enough. It is not a job of opening Search Console every time.

Takeaways

Domain vs. URL prefix is a difference in visible range. Prefix still covers pages under it
Domain verification is a DNS TXT record. Host is @, value is google-site-verification=...
If site: only shows the homepage, suspect missing index before ranking
The sitemap field takes only sitemap.xml. A page URL gives an HTML error
“Processed successfully” means you handed over the candidate list
For one page you want listed sooner, use URL Inspection. You do not need to resubmit on every update

The work order is: verify the property → submit sitemap.xml → if needed, URL-inspect only important pages → then just deploy. For a few days to a few weeks, watch the index count on the Pages menu.