Sitemap ping removal and alternative-language sitemap annotations

Older tutorials told site owners to "ping" Google whenever a page changed, by visiting a URL like https://www.google.com/ping?sitemap=.... That endpoint is gone. Google deprecated the unauthenticated sitemap ping in 2023 and the endpoint stopped functioning early in 2024, so any code or plugin still hitting it no longer does anything useful, and the request now returns a 404. Nothing broke: the change only removed a method that Google said produced mostly spam and little value. What replaced the ping is a mix of submission and an accurate page-level signal.

Why the ping is gone

The sitemap protocol originally defined an unauthenticated REST method for submitting sitemaps to search engines. Google's internal studies and the other engines that participated showed these submissions were not very useful, and in Google's case the vast majority were spam. So support was deprecated, the endpoint stopped functioning, and HTTP requests to it began returning the 404. You do not need to fix any code that still calls it: the request is harmless but pointless, so the correct action is to remove the call so it no longer gives a false sense of having notified Google.

Submit the modern way

Two supported paths replace the ping:

• Search Console: submit the sitemap under Sitemaps, and the report shows whether Google accepted and parsed it.
• robots.txt: add a Sitemap: line pointing at the sitemap URL. Google reads this line and discovers the file without any explicit ping. The image sitemap and sitemap XML articles cover the file structures. Note the Sitemaps report only lists sitemaps submitted there or via the Indexing API; a robots.txt-declared sitemap is crawled and discovered but is not listed in that report.

Because there is no ping, the freshness signal that used to ride on it now lives in an accurate <lastmod>. Search Console reads lastmod for crawl scheduling, so a sitemap that stamps every page with today's date teaches the crawler nothing honest. The sitemap change frequency article explains how to keep lastmod truthful and how Google treats the related changefreq values.

Mark alternative languages

A sitemap is also the cleanest place to describe pages that exist in several languages. Google reads hreflang annotations from the HTML head, an HTTP header, or the sitemap, and it recommends picking one method rather than stacking several, because conflicting declarations get ignored. For a large multilingual site the sitemap is usually the easiest place to centralise them.

Inside the sitemap, each language version appears as its own <url> block, and each block lists every version with an xhtml:link rel="alternate" element, including a self-reference:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/about/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/ueber/"/>
  </url>
  <url>
    <loc>https://example.com/de/ueber/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/ueber/"/>
  </url>
</urlset>

Three details trip people up:

• The xmlns:xhtml namespace declaration on the root element is required, or the annotations are ignored.
• Every version must include the full set of links including itself; missing the self-reference is a common silent error.
• Keep the hreflang method consistent, sitemap or inline, and never ship both for the same URLs. The hreflang basics article covers the language codes and reciprocity rules.