Content Site Sitemap Not Resubmitted After Update

You shipped a batch of 50 new articles. A week later Search Console still shows the same URL count it had before the launch, and your new pages do not appear in site: searches. The build succeeded, the sitemap is live, but Google has not noticed.

Fastest fix (most cases): make sure each new URL carries an accurate <lastmod>, confirm robots.txt advertises the sitemap, then open Search Console > Sitemaps and re-add the sitemap URL to force a fresh read. That covers the two signals Google actually acts on. Do not reach for the old google.com/ping or bing.com/ping URLs — both were retired (more on that below).

Search engines do not poll sitemaps aggressively. They re-fetch on a schedule driven by prior crawl history, the lastmod values they see, and explicit resubmission. A sitemap that exists is not the same as a sitemap that has been read.

Important — the ping endpoints are gone. Google deprecated its /ping?sitemap= endpoint in June 2023; as of June 2026 it returns 404. Bing retired bing.com/ping back in 2022 (now 410 Gone). Any deploy script still curling those URLs is doing nothing. The supported replacements are lastmod + robots.txt + Search Console (manual or API) for Google, and IndexNow for Bing/Yandex/Seznam/Naver.

Which bucket are you in?

Symptom	Most likely cause	Jump to
Live <url> count is lower than your local build	CDN serving a stale sitemap	Cause 1
robots.txt has no Sitemap: line	Sitemap never advertised	Cause 2
Sitemap listed, “Last read” is weeks old	Never resubmitted; low change signal	Cause 3
New articles show old/missing <lastmod>	Crawler sees “nothing changed”	Cause 4
Index file lists shards that 404	Sitemap index out of sync	Cause 5
URLs in sitemap but each is noindex	Pages excluded after fetch	Cause 6

Common causes

1. Sitemap generated but old version still served

The build wrote a new sitemap.xml, but the CDN edge cache returns the old one. The crawler fetches it, sees the old URLs, and ignores the new ones.

How to judge: curl -s https://yoursite.com/sitemap.xml | grep -c '<loc>' — count entries and compare to local dist/sitemap.xml. (Use <loc> rather than <url>; a sitemap index file uses <sitemap>/<loc> and has no <url> tags.)

2. Sitemap URL not declared in robots.txt

If robots.txt has no Sitemap: line, crawlers may never find the sitemap unless you explicitly submit it in Search Console. The Sitemap: directive is the one robots.txt line every engine reads.

How to judge: curl -s https://yoursite.com/robots.txt | grep -i sitemap. Empty output means the sitemap is not advertised.

3. Sitemap was submitted once and never resubmitted

Google re-fetches submitted sitemaps, but the cadence depends on the observed change rate. A site with a low historical update frequency can sit 1-2 weeks between reads. Resubmitting does not force indexing, but it re-queues the file for Googlebot’s next crawl cycle.

How to judge: Search Console > Sitemaps > look at the “Last read” column.

4. lastmod dates not updated

Since the ping endpoint went away, Google explicitly leans on <lastmod> to schedule re-crawls of URLs it already knows. If your build emits stale or identical lastmod values, the crawler sees no signal that anything changed and deprioritizes the re-fetch. Google’s own guidance: a lastmod is only useful if it is accurate and verifiable against the page content — fake “always today” timestamps get ignored.

How to judge: open sitemap.xml and confirm new articles have a recent <lastmod>, and that existing articles’ lastmod reflects their latest real edit. If every entry shows the same build timestamp, see sitemap lastmod always today.

5. Sitemap index out of sync with its shards

Big sites use a sitemap index that points at multiple per-section (or per-language) sitemaps. If new articles went into a shard but the index still references an old file — or a shard returns 404 — the crawler never discovers the new content.

How to judge: curl -s https://yoursite.com/sitemap-index.xml and confirm every sub-sitemap is listed and returns 200:

curl -s https://yoursite.com/sitemap-index.xml \
  | grep -oE 'https://[^<]+\.xml' \
  | while read u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done

Every line should start with 200.

6. New URLs blocked by robots.txt or noindex

The sitemap lists the URLs, but each page carries <meta name="robots" content="noindex"> or is disallowed in robots.txt. The crawler fetches, sees the exclusion, and drops the page — Search Console reports Submitted URL marked 'noindex' or Submitted URL blocked by robots.txt.

How to judge: curl -s <new-article-url> | grep -i 'noindex' should produce no match. Then check robots.txt for any Disallow: covering the new path. If you see a conflict, read robots meta vs sitemap conflict.

Before you start

• Confirm the new articles are actually live (open one in a browser, view source).
• Note when the deploy completed — re-fetch timing is measured from there.
• Have Search Console access for the exact property (URL-prefix vs Domain property matters; the sitemap must be under the verified property).

Information to collect

• curl -s https://yoursite.com/sitemap.xml | head -50 — first entries and structure.
• Total <loc> count from the live sitemap.
• robots.txt content.
• Search Console > Sitemaps > status and “Last read” date.
• Search Console > Pages (the “Page indexing” report) > whether new URLs appear under “Discovered - currently not indexed” or “Crawled - currently not indexed”.

Step-by-step fix

Step 1: Verify the on-disk and live sitemaps match

# Local
grep -c '<loc>' dist/sitemap.xml
head -3 dist/sitemap.xml

# Live
curl -s https://yoursite.com/sitemap.xml | grep -c '<loc>'
curl -s https://yoursite.com/sitemap.xml | head -3

The counts should match. If live is lower, you have a CDN cache problem — purge per the CDN stale after rebuild guide, then re-check.

Step 2: Make robots.txt advertise the sitemap

public/robots.txt:

User-agent: *
Allow: /

Sitemap: https://yoursite.com/sitemap-index.xml

Use the index URL if you have one, otherwise sitemap.xml. Multiple Sitemap: lines are allowed (list every shard or just the index). After rebuild, curl -s https://yoursite.com/robots.txt must show the Sitemap: line.

Step 3: Fix <lastmod> so it carries a real signal

Because the ping endpoints are dead, lastmod is now the primary signal that tells Google “re-crawl this.” Source it per-article, not from build time.

Astro example (astro.config.mjs with @astrojs/sitemap):

import sitemap from "@astrojs/sitemap";

export default defineConfig({
  integrations: [
    sitemap({
      serialize(item) {
        // map each URL back to its article's real updated date
        item.lastmod = lastmodForUrl(item.url); // your frontmatter updatedAt
        item.changefreq = "weekly";
        item.priority = 0.7;
        return item;
      },
    }),
  ],
});

Pull lastmod from the frontmatter’s updatedAt (fall back to publishedAt if the article has not been edited). Do not stamp every entry with new Date() at build time — Google treats uniformly-fresh timestamps as noise and ignores them.

Step 4: Resubmit in Search Console

search.google.com/search-console > pick the property > Sitemaps (left nav).

Add a new sitemap:
  https://yoursite.com/sitemap-index.xml
Submit

Google reads it within minutes for an active property, longer for a new one. If a sitemap is already listed and shows Couldn't fetch or a stale “Last read”:

1. Remove it from the list.
2. Re-add the same URL.
3. The remove + re-add forces a fresh fetch.

Step 5 (optional): Automate the Search Console resubmit via API

The supported programmatic replacement for the old ping is the Search Console API sitemaps.submit method (scope https://www.googleapis.com/auth/webmasters). It is a PUT to:

https://www.googleapis.com/webmasters/v3/sites/{SITE_URL}/sitemaps/{FEEDPATH}

where {FEEDPATH} is the URL-encoded sitemap URL. A successful call returns an empty 200 body. Wire it into a deploy step with a service-account token to re-queue the sitemap on every release — this is the legitimate “auto-resubmit” path, not a curl to /ping.

Step 6: Notify Bing and the rest via IndexNow

Bing, Yandex, Seznam, Naver, and Yep no longer accept sitemap pings; they use IndexNow. You host a key file at https://yoursite.com/<key>.txt (the key is 8-128 characters from a-z, A-Z, 0-9, and -, and is the file’s only content — it is public by design so the engine can verify ownership), then POST changed URLs:

curl -s -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "yoursite.com",
    "key": "YOUR_KEY",
    "keyLocation": "https://yoursite.com/YOUR_KEY.txt",
    "urlList": ["https://yoursite.com/articles/new-article-slug/"]
  }'

Up to 10,000 URLs per call; a 200 or 202 means accepted. Note: Google does not consume IndexNow (as of June 2026), so this speeds up Bing/Yandex/etc. only — for Google you still rely on Steps 3-5. This site already runs an IndexNow ping as a postbuild step (scripts/ping-indexnow.mjs), so for most deploys this is automatic.

Step 7: Use URL Inspection for priority pages

For cornerstone new pages, push them individually in Search Console:

Top search bar in Search Console > paste URL > Inspect
> "URL is not on Google" > Request Indexing

This is rate-limited (roughly a handful of requests per property per day, and Google may temporarily pause the queue under load), so reserve it for your highest-value pages, not the whole batch.

How to confirm it’s fixed

• curl -s https://yoursite.com/sitemap.xml | grep -c '<loc>' matches your expected total.
• Search Console > Sitemaps > “Last read” updates to today’s date and status is Success.
• The “Discovered URLs” count in the Sitemaps report climbs toward your new total within a few days.
• site:yoursite.com/articles/new-article-slug returns the page within ~3-7 days.
• New articles appear under Search Console > Pages > “Indexed” within 1-2 weeks (authority-dependent).

Long-term prevention

• Always advertise the sitemap in robots.txt — one line that removes a whole class of discovery failures.
• Emit accurate per-URL <lastmod>; treat it as the primary “re-crawl me” signal now that pinging is gone.
• Automate the Search Console API resubmit and the IndexNow POST in your deploy pipeline so “submit sitemap” leaves the manual release checklist.
• For sites over 50,000 URLs (or sitemaps approaching 50 MB uncompressed), split into a sitemap index with per-section shards — see sitemap 50k URL limit split.
• Check the Search Console Pages report weekly; stalled discovery or a sudden drop is an early warning.

Common pitfalls

• Curling google.com/ping?sitemap=... or bing.com/ping?sitemap=... and assuming it worked — both 404/410 now and do nothing.
• Submitting a sitemap URL without first confirming it returns 200; if it 404s, the submission silently fails.
• Listing URLs blocked by robots.txt — Search Console flags Submitted URL blocked by robots.txt.
• Stamping every <lastmod> with the build time — Google ignores uniformly-fresh timestamps.
• Mixing http:// and https:// (or www/non-www) URLs in the sitemap; pick the canonical host and use it everywhere.

FAQ

Q: I removed the curl ping from my deploy — what replaces it? A: Nothing for triggering Google directly; that capability is gone. Google now schedules re-crawls off <lastmod> plus Search Console submission. Use the Search Console API sitemaps.submit if you want an automated resubmit, and IndexNow to cover Bing/Yandex/etc.

Q: Does resubmitting a sitemap force Google to index the pages? A: No. It re-queues the sitemap for Googlebot’s next crawl and re-discovers new or changed URLs. Indexing still depends on page quality and site authority.

Q: How fast will new URLs get indexed? A: Discovery typically lands within 24-48 hours of a successful read; full indexing usually takes 3-14 days depending on authority. If pages stay at “Discovered - currently not indexed” longer, see discovered currently not indexed.

Q: Should I include images in the sitemap? A: Optional. Image sitemap extensions help image search but are not required for normal page indexing. Add them after the core sitemap is healthy.

Related

• Sitemap not found
• Sitemap submitted not indexed
• Sitemap lastmod always today
• Sitemap pages missing from search console
• Sitemap references old domain
• Robots meta vs sitemap conflict

Tags: #content-site #Ops #Troubleshooting

Related Articles

Troubleshooting

Internal Link Rot: Articles Point to Renamed or Deleted Slugs

Half your internal links 404 because you renamed slugs without redirects. Add host-level 301s, run lychee in CI, and fail prebuild on any link that points at a slug that does not resolve.

May 24, 2026 #Content ops #Site quality

Troubleshooting

Canonical Points to the Wrong Page: Translations Canonicalize Back to English

ZH pages carry a canonical that points at the EN version, so Google deindexes the ZH variant. Fix: self-referential per-page canonical, verify with curl + view-source.

May 24, 2026 #Content ops #Site quality

Troubleshooting

FAQ Rich Result Gone in Google? It's Deprecated, Not Your Schema

Your FAQPage JSON-LD looks right but the FAQ rich result never shows. As of May 7 2026 Google deprecated FAQ rich results for everyone. Confirm it, then decide keep vs remove.

May 24, 2026 #Content ops #Site quality

Troubleshooting

Hreflang Misconfigured Between EN and ZH: No Return Tags, Wrong Codes, Missing x-default

Hreflang pairs don't reciprocate, language codes don't match (zh vs zh-CN), x-default missing. Auto-emit from translationKey, validate with the Merkle hreflang tester, fix at the source.

May 24, 2026 #Content ops #Site quality

Troubleshooting

Image Alt Text Missing in Bulk: Audit, Backfill, and Lock It In

Hundreds of images with no alt attribute hurt accessibility, image search, and AdSense quality. Audit by category, backfill by traffic, then fail the build on regressions.

May 24, 2026 #Content ops #Site quality

Troubleshooting

Publish Date Stuck in the Past: Articles Look Stale After Real Refreshes

Your publishedAt never moves so SERP shows an old date. Add updatedAt, show ONE date, match schema to the visible date, and bump only on substantial edits.

May 24, 2026 #Content ops #Site quality