How to submit sitemaps and check indexing with the Google Search Console API

Every deploy of this site leaves the same three jobs: tell Google the sitemaps changed, find out which new pages Google has actually indexed, and tell Bing which URLs changed. Done by hand in Search Console, that means opening the Sitemaps report, pasting URLs into URL Inspection one at a time and clicking Request indexing until the quota runs out.

We moved the whole job into a few commands that run after each deploy. This guide shows how we built them with the Google Search Console API, step by step, using the real output from luminousdigitalvisions.com on October 9, 2026: seven sitemaps submitted, five stale ones removed and 116 recently changed URLs checked in one pass. It also covers the Indexing API, which many site owners use to push ordinary pages to Google, how it works and why we chose not to use it.

It's written for developers, technical SEOs and site owners who are comfortable running a Node script. The examples use Node 18 or later, with no dependencies except in the Indexing API step.

What each API can and can't do

"Submit to Google" covers several different tools, and only some of them have an API. This table is the map for the rest of the guide.

The old sitemap ping URL is gone as well. In June 2023 Google announced it was retiring the sitemaps ping endpoint, because most of the unauthenticated submissions it received were spam. That leaves three supported ways to hand Google a sitemap: the Sitemaps report, the Search Console API and a Sitemap line in robots.txt.

Any of them is a request, not an instruction. Google's sitemap documentation calls submission "merely a hint", and its recrawl guidance says crawling can take anywhere from a few days to a few weeks. Automation removes the clicking. It doesn't change how quickly Google decides to index a page.

Before you start

• A verified Search Console property, with your account as an owner or full user. Google's permissions table allows only those two roles to submit sitemaps.
• The property name exactly as Search Console stores it. A Domain property looks like sc-domain:example.com, and a URL-prefix property is the full URL with its trailing slash, such as https://example.com/. Ours is sc-domain:luminousdigitalvisions.com.
• A Google Cloud project with the Google Search Console API enabled.
• Credentials. We use an OAuth client of the Desktop app type, because the commands run from a laptop after each deploy. In a CI pipeline, a service account added as a full user on the property does the same job.
• A sitemap that's accurate before you submit it, which step 2 covers.

Step 1: Authorize once and keep a refresh token

The Search Console API has two OAuth scopes. webmasters.readonly is enough to read data, including URL Inspection. Submitting or deleting a sitemap needs the full https://www.googleapis.com/auth/webmasters scope.

We found that out the slow way. Our reporting script had been authorized with the read-only scope when we built it, which was fine for pulling search performance data. Its first sitemap submission came back with HTTP 403. The property and the sitemap were fine; the token simply had no permission to write. Re-authorizing with the full scope fixed it, and the script now prints that advice whenever a sitemap call returns 403.

Authorization happens once. Send the browser to Google's consent page with access_type=offline, so that Google returns a refresh token:

// One-time authorization. Open this URL in a browser and approve.
const consent = new URL('https://accounts.google.com/o/oauth2/v2/auth');
consent.search = new URLSearchParams({
  client_id: process.env.GOOGLE_CLIENT_ID,
  redirect_uri: 'http://localhost:8080/callback', // loopback, for a Desktop app client
  response_type: 'code',
  scope: 'https://www.googleapis.com/auth/webmasters',
  access_type: 'offline', // ask for a refresh token
  prompt: 'consent',      // return one even if you approved this app before
});
console.log(consent.toString());

Google redirects to the loopback address with a code parameter. Our script runs a small local server on a random port to catch it, but for a one-off you can let the redirect fail and copy the code from the address bar. Exchange it for tokens and keep the refresh token somewhere private, such as a git-ignored .env file or a secrets manager:

const response = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  body: new URLSearchParams({
    code,                                  // from the ?code= on the redirect
    client_id: process.env.GOOGLE_CLIENT_ID,
    client_secret: process.env.GOOGLE_CLIENT_SECRET,
    redirect_uri: 'http://localhost:8080/callback',
    grant_type: 'authorization_code',
  }),
});
const {refresh_token} = await response.json(); // store privately, never commit it

From then on, each run trades the refresh token for a short-lived access token:

async function accessToken() {
  const response = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    body: new URLSearchParams({
      client_id: process.env.GOOGLE_CLIENT_ID,
      client_secret: process.env.GOOGLE_CLIENT_SECRET,
      refresh_token: process.env.GOOGLE_REFRESH_TOKEN,
      grant_type: 'refresh_token',
    }),
  });
  if (!response.ok) throw new Error(`Token refresh failed: ${response.status} ${await response.text()}`);
  return (await response.json()).access_token;
}

One trap catches nearly everyone. If your OAuth consent screen is set to External and its publishing status is still Testing, Google's OAuth documentation says the refresh token expires after seven days. The symptom is an invalid_grant error a week after everything worked, and we hit it during this project. Either publish the consent screen or plan to re-authorize. Refresh tokens also stop working after six months without use, or when someone revokes the app's access.

Step 2: Make the sitemap worth submitting

Submitting a sitemap quickly doesn't help if the sitemap misleads Google. Check three things before automating anything.

Every URL in it should be the canonical version, return a 200 and be allowed by robots.txt. A sitemap full of redirects and noindexed pages teaches Google to trust it less.

The lastmod dates have to be honest. Google uses lastmod only when it is "consistently and verifiably" accurate, and it ignores priority and changefreq completely. Many build tools stamp every URL with the build date, which makes the field useless. Our build compares each page's rendered main content with the previous commit and changes lastmod only when that content changed, so a rebuild that changes nothing leaves every date alone.

Large sites read better in sections. Our sitemap.xml is an index pointing to six files (pages, services, industries, locations, case studies and the blog) with 169 URLs between them. Google's limit is 50,000 URLs or 50MB uncompressed per file, so for us the split is about reporting rather than size: the Sitemaps report shows each section's status on its own line, and a problem in one section stands out. The index is also listed in robots.txt, so Google can find it without any submission.

Step 3: Submit every sitemap through the API

Submission is a PUT request with no body. The property name and the sitemap URL both go in the path, and both must be URL-encoded:

const SITE = 'sc-domain:example.com'; // exactly as Search Console lists it
const base = `https://www.googleapis.com/webmasters/v3/sites/${encodeURIComponent(SITE)}/sitemaps`;
const token = await accessToken();
const headers = {Authorization: `Bearer ${token}`};

const feeds = [
  'https://example.com/sitemap.xml',
  'https://example.com/sitemap-pages.xml',
  'https://example.com/sitemap-blog.xml',
];
for (const feed of feeds) {
  const response = await fetch(`${base}/${encodeURIComponent(feed)}`, {method: 'PUT', headers});
  if (!response.ok) throw new Error(`HTTP ${response.status} submitting ${feed}`);
  console.log(`Submitted ${feed}`);
}

A successful call returns an empty body. To see what Google did with it, list the property's sitemaps:

const {sitemap = []} = await (await fetch(base, {headers})).json();
for (const entry of sitemap) {
  const pages = (entry.contents || [])
    .filter(item => item.type === 'web')                     // skip the image row
    .reduce((sum, item) => sum + Number(item.submitted || 0), 0); // counts arrive as strings
  console.log(`${entry.path}: last submitted ${entry.lastSubmitted}, last read ${entry.lastDownloaded}, ` +
    `${pages} pages, ${entry.errors} errors, ${entry.warnings} warnings${entry.isPending ? ', pending' : ''}`);
}

Each entry has lastSubmitted, lastDownloaded (when Google last read the file), isPending (true until Google processes the new submission), errors, warnings and a contents array with the number of URLs submitted.

Read that contents array carefully. It holds one row per content type, so a sitemap that lists images next to its pages returns a web row and an image row. Our first version added them together and reported 336 URLs for a site with 169 pages. Count the web row only. The counts arrive as strings, so convert them before adding, and ignore the indexed field, which Google's reference marks as deprecated.

Here is part of the real run, trimmed to fit. Every file came back with zero errors, and the ones Google hadn't re-read yet show as pending:

Submitted https://luminousdigitalvisions.com/sitemap.xml
Submitted https://luminousdigitalvisions.com/sitemap-pages.xml
Submitted https://luminousdigitalvisions.com/sitemap-industries.xml
Submitted https://luminousdigitalvisions.com/sitemap-locations.xml
Submitted https://luminousdigitalvisions.com/sitemap-case-studies.xml
Submitted https://luminousdigitalvisions.com/sitemap-blog.xml
Submitted https://luminousdigitalvisions.com/sitemap-services.xml
  .../sitemap-services.xml: last submitted 2026-10-10T00:16:04.480Z, last read 2026-10-08T15:19:57.071Z, 18 pages, 0 errors, 0 warnings, pending
  .../sitemap-blog.xml: last submitted 2026-10-10T00:16:04.024Z, last read 2026-10-07T12:38:01.739Z, 76 pages, 0 errors, 0 warnings, pending
  .../sitemap-locations.xml: last submitted 2026-10-10T00:16:02.986Z, last read 2026-10-08T09:57:44.649Z, 17 pages, 0 errors, 0 warnings, pending
  .../sitemap.xml: last submitted 2026-10-10T00:15:58.855Z, last read 2026-10-10T00:01:26.662Z, 169 pages, 0 errors, 0 warnings, pending

Step 4: Remove sitemaps you no longer publish

The list call showed something we hadn't expected. Search Console was still tracking five sitemaps that were no longer part of our build: two copies of an old feed (one on the www host), a www copy of the main sitemap, an old sitemap-lp.xml and a previous sitemap index. Four of them reported errors. Google had read every one of them since early September, and the www copy on October 7, so it was still spending visits on files nobody maintained.

Removing a sitemap uses the same URL with DELETE:

const current = new Set(feeds);
for (const entry of sitemap.filter(entry => !current.has(entry.path))) {
  const response = await fetch(`${base}/${encodeURIComponent(entry.path)}`, {method: 'DELETE', headers});
  if (!response.ok && response.status !== 404) throw new Error(`HTTP ${response.status} removing ${entry.path}`);
  console.log(`Removed ${entry.path}`);
}

A delete is harder to undo than a submit, so our script only marks stale entries as [not in this build] by default and removes them when run with --prune. The image at the top of this article is that run:

  https://luminousdigitalvisions.com/feed.xml: ... 77 pages, 1 errors, 0 warnings  [not in this build]
  https://www.luminousdigitalvisions.com/sitemap.xml: ... 169 pages, 0 errors, 0 warnings  [not in this build]
  https://luminousdigitalvisions.com/sitemap-lp.xml: ... 17 pages, 1 errors, 0 warnings  [not in this build]
  https://luminousdigitalvisions.com/sitemap-index.xml: ... 186 pages, 1 errors, 0 warnings  [not in this build]
  https://www.luminousdigitalvisions.com/feed.xml: ... 77 pages, 1 errors, 1 warnings  [not in this build]
Removed https://luminousdigitalvisions.com/feed.xml
Removed https://www.luminousdigitalvisions.com/sitemap.xml
Removed https://luminousdigitalvisions.com/sitemap-lp.xml
Removed https://luminousdigitalvisions.com/sitemap-index.xml
Removed https://www.luminousdigitalvisions.com/feed.xml

Know what removal does and doesn't do. Google's Sitemaps report help says deleting a sitemap removes it from the report, but Google won't forget the sitemap or the URLs listed in it. If an old file shouldn't be read at all, make it return a 404 as well.

Step 5: Check index status in bulk

The URL Inspection API gives you, for one URL per call, the same information as the URL Inspection tool in Search Console:

async function inspect(url) {
  const response = await fetch('https://searchconsole.googleapis.com/v1/urlInspection/index:inspect', {
    method: 'POST',
    headers: {...headers, 'Content-Type': 'application/json'},
    body: JSON.stringify({inspectionUrl: url, siteUrl: SITE, languageCode: 'en-US'}),
  });
  if (!response.ok) throw new Error(`HTTP ${response.status} inspecting ${url}`);
  return (await response.json()).inspectionResult?.indexStatusResult ?? {};
}

The fields worth keeping are verdict (such as PASS or NEUTRAL), coverageState (the same wording as the Page indexing report), lastCrawlTime, pageFetchState, robotsTxtState and the two canonicals: googleCanonical, the URL Google chose, and userCanonical, the one your page declares. When those two differ, Google is indexing a different URL from the one you asked for.

The usage limits are 2,000 inspections a day and 600 a minute per property. That covers a small site easily, but inspecting every URL after every deploy wastes the allowance on pages that haven't changed. Our script reads the local sitemap files, keeps only URLs whose lastmod falls in the last 14 days, waits 150 milliseconds between calls, stops at the first HTTP 429 and writes one CSV row per URL. Flags widen it when needed: --all inspects everything, --since sets the start date and --limit caps the count.

// urls: [{url, lastmod}] read from your own sitemap files
const since = new Date(Date.now() - 14 * 86400000).toISOString().slice(0, 10);
const recent = urls.filter(item => item.lastmod >= since).slice(0, 2000);
const rows = [];
for (const {url, lastmod} of recent) {
  try {
    const status = await inspect(url);
    rows.push([url, lastmod, status.verdict, status.coverageState, status.lastCrawlTime,
      status.pageFetchState, status.robotsTxtState, status.googleCanonical, status.userCanonical]);
  } catch (error) {
    rows.push([url, lastmod, 'ERROR', error.message]);
    if (error.message.includes('HTTP 429')) break; // quota reached: keep what you have
  }
  await new Promise(resolve => setTimeout(resolve, 150)); // about 400 a minute, under the 600 limit
}
// write rows to a CSV and print a count per coverageState

Our run on October 9 inspected the 116 URLs that had changed since September 26. The output, trimmed:

Inspecting 116 URL(s) changed since 2026-09-26. Google allows 2000 inspections a day for this property.

Coverage summary:
  75  Submitted and indexed
  30  URL is unknown to Google
  10  Discovered - currently not indexed
  1  Crawled - currently not indexed

Not indexed yet (41). Request indexing in Search Console only for the ones that matter most:
  https://luminousdigitalvisions.com/about/  (URL is unknown to Google)
  https://luminousdigitalvisions.com/industries/restaurants/  (Discovered - currently not indexed)
  https://luminousdigitalvisions.com/industries/arizona/hvac/  (Discovered - currently not indexed)
  https://luminousdigitalvisions.com/locations/california/santa-clara-county/  (Discovered - currently not indexed)
  https://luminousdigitalvisions.com/locations/california/san-francisco/  (Discovered - currently not indexed)
  https://luminousdigitalvisions.com/locations/california/alameda-county/  (URL is unknown to Google)
  ...

Full report: .../.reports/index-status-2026-10-10.csv

That split is the useful part. "Unknown" a day after launch needs patience. "Discovered" needs patience and links from pages Google already visits often. "Crawled, currently not indexed" means Google fetched the page and wasn't convinced, which is a content question that no amount of resubmitting will answer.

Keep in mind what the API reports: the version Google has stored. When Google launched the URL Inspection API in January 2022, it described it as returning the indexed information available in the URL Inspection tool, and the Test live URL button still has no API equivalent. When a result looks wrong, run the live test by hand. That is how we traced a client's lost traffic to a hosting firewall returning 403 errors to Googlebot while the pages loaded normally for everyone else.

Step 6: Request indexing by hand for a few pages

The Request indexing button has no API. Google's recrawl guidance says you must be an owner or full user, that there is a quota, and that requesting a recrawl of the same URL several times won't get it crawled any faster.

So the CSV becomes a shortlist. Of the 41 URLs that weren't indexed, only a handful are worth a manual request: the pages that matter most commercially, such as our new AI receptionist service, the AI search optimization service and the about page. The new pages listed on our locations page are left to the sitemap and the links pointing at them. A few manual requests take a couple of minutes, and they go to the pages where a few days' difference matters.

Step 7: The Indexing API, which works but we don't advise

Disclaimer: we don't use the Indexing API on our own site or on client sites, and we don't recommend it for ordinary pages. Google's documentation says it can only be used for pages with JobPosting structured data or a BroadcastEvent embedded in a VideoObject, so using it for anything else falls outside Google's stated terms. We include it because people ask about it and because it does work in the sense they mean: after a notification, Googlebot fetches the URL, and you can see the visit in your server logs. Whether the page is then indexed is still Google's decision.

Our reasons for leaving it alone are practical. The Indexing API quickstart says every submission goes through spam detection and that abuse, including using multiple accounts to get around quotas, may result in access being revoked. A crawl isn't indexing, so if a page isn't good enough to index, fetching it sooner only gets the same answer sooner. And the setup makes a service account an owner of your Search Console property, which is far more access than a notification script should have.

If you use it anyway, whether for the job listings and livestreams it was built for or on other pages knowing the risk, the setup is:

1. In the same Cloud project, enable the Indexing API and create a service account with a JSON key.
2. Add the service account's email address as an owner of the property in Search Console. Google's prerequisites call for owner status; full user isn't enough.
3. Authorize with the https://www.googleapis.com/auth/indexing scope and send one POST per URL to urlNotifications:publish, with type URL_UPDATED for a new or changed page or URL_DELETED for a removed one.

// npm install google-auth-library
import fs from 'node:fs';
import {JWT} from 'google-auth-library';

const key = JSON.parse(fs.readFileSync('service-account.json', 'utf8'));
const client = new JWT({
  email: key.client_email,
  key: key.private_key,
  scopes: ['https://www.googleapis.com/auth/indexing'],
});

const response = await client.request({
  url: 'https://indexing.googleapis.com/v3/urlNotifications:publish',
  method: 'POST',
  data: {url: 'https://example.com/jobs/senior-electrician', type: 'URL_UPDATED'},
});
console.log(response.data.urlNotificationMetadata);

The default quota is 200 notifications a day per project, and a GET to urlNotifications/metadata with the encoded URL returns the last notification Google received for it. If you go ahead, keep the volume low and send only pages you'd be comfortable having a person at Google review.

Step 8: Tell Bing and others with IndexNow

Google isn't part of IndexNow. The participating engines listed on indexnow.org are Microsoft Bing, Naver, Seznam.cz, Yandex and Yep. For those, one request covers up to 10,000 URLs:

const key = 'your-key';                       // also served at https://example.com/your-key.txt
const response = await fetch('https://api.indexnow.org/IndexNow', {
  method: 'POST',
  headers: {'Content-Type': 'application/json; charset=utf-8'},
  body: JSON.stringify({
    host: 'example.com',
    key,
    keyLocation: `https://example.com/${key}.txt`,
    urlList: changedUrls,                      // only URLs whose lastmod changed
  }),
});
// 200 = accepted, 202 = accepted while the key is checked,
// 403 = key file missing or wrong, 422 = URL not on this host, 429 = too many requests

The key file proves the request came from the site owner: a UTF-8 text file at the site root, named after the key and containing nothing but the key. The IndexNow documentation lists a 403 when the key can't be verified, so the file has to stay online for as long as you submit.

Four rules keep our IndexNow runs clean. It runs after the deploy is live, never during the build, because engines fetch straight away and would read the previous version. Every URL is checked for a 200 before it's sent. Only URLs whose lastmod changed since the last successful run go out, tracked in a small JSON state file committed to the repo. Removed URLs are sent too, and they must answer with a redirect or a 404 so engines drop them. Our first submission, on September 17, 2026, sent all 168 URLs on the site at the time and came back 202: accepted, with the key still being checked. Runs since then send only the changes, because the documentation lists 429 as "Too Many Requests (potential Spam)", and resending an unchanged list on a schedule invites it.

Step 9: Make it a post-deploy routine

# straight after the deploy is live
npm run indexnow                  # Bing and other IndexNow engines, changed URLs only
npm run google:submit-sitemaps    # resubmit the index and its six section sitemaps

# three to five days later
npm run google:index-status       # inspect URLs changed in the last 14 days, write a CSV

# occasionally
npm run google:submit-sitemaps -- --dry-run   # preview without submitting anything
npm run google:submit-sitemaps -- --prune     # remove sitemaps that are no longer in the build

The order matters. IndexNow and the sitemap submission run as soon as the deploy is live and the new pages return a 200. The index status check waits three to five days, because inspecting a page Google hasn't had time to crawl only tells you it's unknown.

After that, the CSV is the to-do list. New pages still unknown after a week get checked for links from other pages on the site. Pages marked "Crawled, currently not indexed" get a content review. Only the few that matter most commercially get a manual Request indexing.

Common errors and fixes

We hit the first two and the last one ourselves. The others are the usual cause when a working script is pointed at a new property.

Where this fits

None of this makes a page rank. It shortens the gap between publishing a page and knowing whether Google has it, and it turns "is the new page indexed yet?" into a CSV you can act on. What decides whether those pages get indexed and found is the rest of technical SEO: fast pages, honest sitemaps, consistent canonicals and links from pages Google already trusts. Our technical SEO guide covers those checks, and our guide to monitoring local SEO covers the reporting side. If your site is a JavaScript single-page app, read why Google can't index some React sites before blaming submission.

We set up this kind of reporting as part of our SEO services, usually alongside a website build where the sitemap and lastmod logic are written into the code from the start. The Freshly Folded case study shows what that monitoring looks like on a live client site.

Questions about the Search Console API

If new pages are stuck at "Discovered, currently not indexed" and you'd like a second opinion, book a call and bring the URL list.

Sources

• Google for Developers, Search Console API: Sitemaps submit and the Sitemaps resource.
• Google for Developers, URL Inspection API: index.inspect.
• Google for Developers, Search Console API usage limits.
• Google Search Central Blog, Introducing the new Search Console URL Inspection API (January 2022).
• Google Search Central Blog, Sitemaps ping endpoint is going away (June 2023).
• Google Search Central, Build and submit a sitemap.
• Google Search Central, Ask Google to recrawl your URLs.
• Search Console Help, Manage your sitemaps using the Sitemaps report and Managing owners, users, and permissions.
• Google for Developers, Indexing API quickstart, prerequisites and usage guide.
• Google for Developers, Using OAuth 2.0 to access Google APIs (refresh token expiration).
• IndexNow, protocol documentation.