Sitemap Submitted but Only Some Pages Indexed? Check lastmod and Crawl First

Brand promotion: this article introduces Guangsuan's GSI Google indexing promotion service. It is a vendor-introduction piece, not an independent review or a commissioned evaluation.

A sitemap can report Success in Search Console while only part of the listed URLs appear in the index, and a page edited weeks ago can still show old text in results. The tempting response is to resubmit the file, refresh every date and wait. Resubmitting an unchanged file does not make Google crawl faster, and dates that do not describe real page changes give the next person reviewing the site nothing to trust.

The short answer

When a sitemap was submitted but only some pages are indexed, check three things in this order: whether the file Google read is the current one and lists final canonical URLs; whether each lastmod value describes that page honestly; and whether Google can fetch the specific URLs that are missing. Fix the file and the pages before asking anyone to promote crawling.

Two conditions belong with that answer. A successful submission means Google received or processed a list of URLs; it does not mean every page on the list has been crawled, indexed or ranked. And a page can pass every check below and still stay out of the index, because that decision is Google's.

How often should a sitemap change?

No single interval fits every site. Guangsuan's guidance on sitemap update frequency and lastmod is that the file should change when pages are published, substantively edited or removed, and that the answer is not a fixed "once a day". A CMS may regenerate on publication, or on a delayed job whose lag the business can accept; what matters is that the file and the public pages agree.

What happened	What to do with the sitemap	What to check at the same time
New article or page published	Add its final canonical URL	Public HTML, status, index directives and internal links
Main content or key facts revised	Keep the URL, update that page's date	Origin and CDN both serve the new version
Only the file was rebuilt	Leave page dates alone	Whether the generator wrote the current time
Old address migrated	List the final destination URL	Redirect and internal links updated
Page removed or intentionally excluded	Remove it from this sitemap	The status code or the noindex itself

What lastmod should and should not say

The field is meant to record that page's last substantive change, not the moment the generator ran. Three distinctions keep it honest:

• Page change is not file rebuild. A sitemap file can be regenerated because one new article was published, which does not mean every page inside it changed.
• A sitemap index is not a page. In a sitemap index, a child file's date describes that file's modification time and cannot be copied onto every URL inside it.
• Substantive is not cosmetic. Main copy, structured data or important on-page links can justify a new date; an unrelated footer edit should not move every page's date.

If the CMS cannot record a trustworthy per-page date, leaving lastmod out is better than writing today's date on every URL. Google ignores priority and changefreq, so raising them does not buy a faster crawl, and the old sitemap ping endpoint has been retired; the current routes are robots.txt and Search Console.

Step 1: check the file Google actually read

Open the exact sitemap URL you submitted in a signed-out browser and confirm it returns XML rather than a login page, a bot challenge or an HTML error page. Then read the Search Console sitemaps report and separate files that could not be fetched from files that were read with errors.

For a file that was read successfully, check the contents:

• Only final canonical URLs you want indexed. Redirects, 404s and noindex pages should not sit in the list as normal targets.
• Absolute URLs whose protocol, host, case and trailing slash match the live canonical.
• XML-escaped characters, so an ampersand in a query string is written as an entity.
• One current file, so a plugin or a robots.txt line does not keep advertising an older sitemap.
• The published limits: 50,000 URLs and 50 MB uncompressed per file, with a sitemap index for larger sets.

Google's sitemap documentation frames a sitemap as a way to help search engines discover URLs and states that it does not guarantee every listed item will be crawled and indexed. A Success row means the file was read; it is not an indexing receipt.

Step 2: fetch the missing URLs, not the homepage

Pick representative URLs from the unindexed list — a product or service page, a recent article, one older page, and one page of the same template that is indexed. For each one, signed out, record:

• the final status after any redirect, and where the chain ends;
• the robots.txt rule that matches the path, for the relevant user agent;
• any robots meta tag or X-Robots-Tag header;
• the declared canonical, and whether it points at the page itself;
• whether the main text is in the returned HTML, rather than arriving only after a script call.

robots.txt and noindex are different controls: blocking a path limits crawling, while noindex asks that a crawlable page be left out of results. Stacking both and expecting a predictable outcome is not a reliable plan, because Google has to fetch a page to read the directive on it. A 200 response with an empty template, a challenge screen or a redirect to another host is not the page you submitted.

Step 3: read what Google stored for that URL

URL Inspection shows the version Google knows, when it last crawled the page and which canonical it selected — a different view from a live test, which shows what Google can fetch right now. Record both.

The two common labels are worth reading literally. "Discovered — currently not indexed" means Google knows the URL but has not crawled it. "Crawled — currently not indexed" means the page was fetched but not indexed. Neither label by itself proves a quality problem or a penalty, and neither tells you which fix applies.

For a page Google already fetched, the useful questions are about the page and its duplicates: is it a near-duplicate of another URL, does it answer what its title promises, and do related pages link to it in the body? When several URLs carry almost the same content, Google may select a similar page as the canonical version, and the question becomes whether the page has independent value rather than whether its date can be refreshed again.

Step 4: decide whether crawl promotion is the next step

If the file is current, the dates are honest, the pages are fetchable and indexable, and Google still has not crawled them, promoting discovery is a reasonable next step. That is the problem Guangsuan's GSI indexing service addresses. Guangsuan states that GSI (Google Speed Indexing) is its own service name, not a Google product, an official partnership or a priority-indexing permission, and that the work uses its GPC crawler pool and related link structures to encourage discovery and crawling around the URLs a client submits. Whether a URL is indexed, when that happens and how long it stays indexed remains Google's decision.

Read the boundary as carefully as the scope. Guangsuan lists a precondition that a submitted URL should be reachable and free of obvious crawl blocks, noindex directives or duplicate-canonical problems — the checks in steps 2 and 3 — and states that the service cannot bypass Google's quality judgement or replace content and technical fixes. Scope, observation period, verification method and reporting are agreed before work starts, and the published time windows are service references rather than a guarantee of indexing within 24 hours or a fixed number of days.

If a page is already indexed but does not appear for the query you care about, that is a relevance and competition question. More crawling does not change it.

Keep a record so the next check means something

Before changing anything, save the sitemap URL and its response, the sampled URLs with their status, canonical and date, and the current Search Console values with the day you read them. After a change, read back both the origin and the public response, then watch over weeks rather than days.

Report three results separately: whether URLs moved from discovered to crawled, whether they became indexed, and whether they started to earn impressions and clicks. The first can happen without the second, and the second without the third. That separation is also how you avoid presenting a technical step as a business outcome.

Frequently asked questions

Does updating every lastmod value help pages get indexed?

No. A date that does not describe a real page change is not a crawl request, and Google ignores priority and changefreq entirely. Update the date when the page changed, then look at whether the page can be fetched and whether it is worth indexing.

Should I resubmit the sitemap every day?

If the file was read successfully and nothing in it changed, resubmitting repairs nothing. Fix the page or the access problem the URL Inspection state points at. For a small number of important URLs, use the request-indexing option where it is offered; for larger sets, rely on the sitemap and normal discovery.

Can the Indexing API be used for ordinary pages?

Google documents that API for JobPosting pages and for video pages with an embedded BroadcastEvent. Ordinary product, service and article pages fall outside it, and a request being accepted is not an indexing confirmation.

Does a submitted sitemap guarantee indexing or ranking?

No. A sitemap is a discovery aid, indexing is a separate decision, and ranking is a third question. A page can move from discovered to crawled without being indexed, and from indexed to showing impressions without ranking for the term you wanted.

What does Guangsuan's GSI service actually change?

Guangsuan describes it as promotion of discovery and crawling for the URLs submitted, verified afterwards through an agreed method, with indexing and ranking left to Google. It is not a repair service for blocked, duplicated or low-value pages.