Sitemaps and indexation: how to get pages indexed faster
Accurate lastmod dates, strong internal links and a fast server help new pages get crawled sooner. Here is what Google documents, and what it does not promise.
Introduction
To get pages indexed faster, publish a sitemap whose lastmod dates are accurate, link to every new page from pages Google already crawls, and keep your server fast and stable. Use Request indexing only for a handful of priority URLs. All of it is a hint to Google, not a command. Google says so itself.
This is a practical guide for teams shipping pages on Next.js or a similar stack. Every fact below comes from Google's own documentation, as of October 2026.
What a sitemap does and does not do
A sitemap tells Google which URLs you want crawled and, optionally, when they last changed. It forces nothing. In Google's words, "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site." That comes from the Build and Submit a Sitemap page, last updated 2026-07-08.
Format and limits
Each sitemap can hold up to 50,000 URLs or 50MB uncompressed. Past that, split it into several files and list them in a sitemap index. Google also asks for fully qualified absolute URLs, UTF-8 encoding, and canonical URLs only. Redirected, duplicate and noindex URLs in the file send mixed signals.
Generate lastmod from real edit dates
The lastmod field is the one part of a sitemap that can change crawl scheduling, and it only works when it is honest. Google says it "uses the lastmod value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." It also defines what counts: an update to the main content, the structured data or the links on the page is significant, while an update to the copyright date is not.
How to wire it
Read lastmod from your content's own updated timestamp, never from the build or deploy time. In a Next.js App Router project, that looks like this:
// app/sitemap.ts
import type { MetadataRoute } from "next";
import { getAllArticles } from "@/lib/articles";
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
const articles = await getAllArticles();
return articles.map((a) => ({
url: `https://example.com/blog/${a.slug}`,
lastModified: a.updatedAt, // the last significant edit, not the deploy
}));
}
If pages are regenerated on a schedule, how ISR works matters here: a page can be rebuilt without its content changing, and that rebuild must not move lastmod.
What to avoid
Do not stamp every URL with today's date on each deploy. Google's 2023 post on the sitemaps ping endpoint stresses that lastmod should reflect genuine modification dates, not act as a crawl trigger. If the dates are wrong, Google learns to ignore them. For pages where the date is unclear, such as a homepage, leaving lastmod out is fine.
Submit the sitemap once, then stop pinging
Google supports four ways to make a sitemap known: the Sitemaps report in Search Console, the Search Console API, a Sitemap: line in robots.txt, and WebSub for Atom or RSS feeds. Pick one or two and leave them alone. Google reads a submitted sitemap regularly, so you do not need to resubmit it after each publish.
The old ping endpoint is deprecated, and the same 2023 post announced it as going away. Don't build a deploy step around it.
Use Request indexing sparingly
The URL Inspection tool lets you ask Google to index a single URL. The Search Console help page is blunt about the limits: there is a daily limit on requests, and "submitting a request does not guarantee that the page will appear in the Google index." Repeating the request for the same URL does not speed it up.
It also gives realistic timing: indexing typically takes a day or so, but can take up to a week or two. For many pages at once, Google's advice is to submit a sitemap with the updated pages marked by lastmod.
Save Request indexing for a launch page or an urgent fix. Let the sitemap carry the rest.
Fix what slows discovery before tuning the sitemap
A perfect sitemap can't rescue a page nothing links to. Google finds most URLs by following links, so link each new page from a page that is already crawled, such as a hub page or a related article. Our guide to internal linking structure for small sites covers the layout, and the Next.js technical SEO audit checklist covers the rest of the crawl basics.
Server behavior matters as well. Google's crawl budget documentation, last updated July 22, 2026, says consistent performance with stable response times lets Google raise crawl capacity, while slowdowns and server errors reduce it. Supporting HTTP caching with 304 Not Modified responses lets Google reuse what it already has.
Know whether crawl budget is your problem
Most sites can skip crawl budget tuning. Google says it applies mainly to sites with over one million unique pages that change weekly, sites with 10,000 or more pages that change daily, and sites where Search Console shows a large share of URLs as "Discovered - currently not indexed." Smaller sites whose pages are indexed soon after publication do not need it.
If you do fit that profile, the documented fixes are plain:
| Symptom | Likely cause | First fix |
|---|---|---|
| Many URLs "Discovered - currently not indexed" | Too many low-value or duplicate URLs | Consolidate duplicates, block unneeded URLs in robots.txt |
| Removed pages keep getting crawled | Blocked instead of removed | Return 404 or 410 for permanently deleted pages |
| Thin pages return 200 | Soft 404s | Return a real error status or add content |
| Slow or erratic crawling | Slow responses or server errors | Speed up responses, support 304 |
One caution from the same page: do not use noindex to save crawl budget, because Google still requests the page before dropping it.
If you want a second pair of eyes on crawl and indexation for a larger site, our SEO and AEO work starts with exactly this audit.
Frequently asked questions
How long does Google take to index a new page?
Google's URL Inspection help says indexing typically takes a day or so, but it can take much longer, up to a week or two in some cases. A sitemap with accurate lastmod values and good internal links is the dependable way to stay near the fast end.
Does submitting a sitemap guarantee indexing?
No. Google calls sitemap submission merely a hint: it does not guarantee that Google will download the sitemap or use it for crawling URLs. Indexing also depends on quality and canonical signals.
Should I request indexing for every new page?
No. There is a daily quota, a request does not guarantee indexing, and repeating it for the same URL does not speed it up. For many pages, Google recommends submitting a sitemap with lastmod.
Do I need to worry about crawl budget?
Usually not. Google says crawl budget management matters mainly for sites with over a million unique pages that change weekly, sites with 10,000 or more pages that change daily, or sites where many URLs sit in Discovered - currently not indexed.
Conclusion
Honest lastmod dates, links from crawled pages and a fast, stable server do most of the work. Treat the sitemap as a hint, Request indexing as a scalpel, and Search Console as the place to check what actually happened rather than the clock.