This guide goes from zero to a site Bing knows about, then covers how to push individual URLs.

Step 1: add the site, the fast way

If your site is already verified in Google Search Console, import it. Bing's import announcement describes the flow:

1. Sign in at bing.com/webmasters.
2. Choose Import under "Import your sites from GSC".
3. Authorize access to your Google account.
4. Select the sites (and their sitemaps) and click Import.

Imported sites are verified automatically. You can import up to 100 sites at a time, within a limit of 1,000 sites per Bing Webmaster Tools account. Bing re-validates ownership by syncing with Search Console, so if you later revoke that access, verify again with another method.

If you don't use Search Console, verify manually with an XML file at the root, a <meta> tag in the home page <head>, or a DNS CNAME record. Traffic data can take up to 48 hours to appear for a newly verified site.

Step 2: give Bing a sitemap

If you imported from Search Console, your sitemaps may already be there. Check Sitemaps in the left menu. Otherwise submit the full URL, for example https://www.example.com/sitemap.xml.

Add it to robots.txt as well, so every crawler finds it:

Sitemap: https://www.example.com/sitemap.xml

The Sitemaps page shows when Bing last read each file, how many URLs it found and any errors. A sitemap stuck on "Pending" for days usually means Bing couldn't fetch it: check that it returns 200 with an XML content type and isn't behind a bot challenge on your CDN.

Step 3: check how Bing sees a page

Bing's URL Inspection tool works like Google's. Paste a URL to see whether it's indexed, when it was crawled and any SEO or markup issues. "Live URL" fetches the page now, which is the quickest way to confirm Bingbot isn't blocked.

From the outside, site:example.com/page on bing.com gives a rough answer for any URL, including pages on sites you don't own.

Step 4: submit URLs directly

Bing gives you two built-in options. The limits below are from Bing's URL Submission help page.

Bing notes that additional quota can be requested through support.

Using the API

Create an API key in Bing Webmaster Tools under Settings > API access. Bing's URL Submission help page, checked on 23 Oct 2026, also describes OAuth 2.0 for setting up the API, so use whichever method your account offers. The examples below use the API key. Then check your quota:

curl -s "https://ssl.bing.com/webmaster/api.svc/json/GetUrlSubmissionQuota?siteUrl=https://www.example.com&apikey=$BING_API_KEY"
# {"d":{"__type":"UrlSubmissionQuota:#Microsoft.Bing.Webmaster.Api","DailyQuota":...,"MonthlyQuota":...}}

And submit a batch:

curl -s -X POST \
  "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrlbatch?apikey=$BING_API_KEY" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
        "siteUrl": "https://www.example.com",
        "urlList": [
          "https://www.example.com/blog/new-post/",
          "https://www.example.com/pricing/"
        ]
      }'

A small Python wrapper that respects the quota:

import os
import requests

API = "https://ssl.bing.com/webmaster/api.svc/json"
KEY = os.environ["BING_API_KEY"]
SITE = "https://www.example.com"


def remaining_quota() -> int:
    r = requests.get(f"{API}/GetUrlSubmissionQuota",
                     params={"siteUrl": SITE, "apikey": KEY}, timeout=30)
    r.raise_for_status()
    return r.json()["d"]["DailyQuota"]


def submit(urls: list[str]) -> None:
    allowed = min(len(urls), remaining_quota())
    if allowed == 0:
        print("No quota left today")
        return
    for i in range(0, allowed, 500):
        batch = urls[i:min(i + 500, allowed)]
        r = requests.post(f"{API}/SubmitUrlbatch", params={"apikey": KEY},
                          json={"siteUrl": SITE, "urlList": batch}, timeout=60)
        print(r.status_code, len(batch))
        r.raise_for_status()

The 500-per-call batch size is a cautious choice. Check Bing's API reference for the current maximum per call.

Should you use the API or IndexNow?

Bing's own help page answers this: Microsoft still supports the URL Submission API, but "adoption of IndexNow is strongly recommended where possible", and the API "may be deprecated in the future". The API only notifies Bing. IndexNow notifies every participating engine, including Yandex, Naver and Seznam, with one request. If you want to set it up, IndexNow in CI shows how to send a notification on every deploy.

Practical advice:

• New integration: use IndexNow.
• Existing API integration that works: keep it, and plan a move to IndexNow.
• Occasional manual submissions: the dashboard URL Submission tool is fine.

Don't run both for the same URLs. You spend quota twice for the same signal.

Why a submitted URL still isn't in Bing

Submission only puts the URL in front of Bingbot. Bing then applies its Webmaster Guidelines. The usual reasons a page stays out:

• Thin or duplicate content, or a page that mostly repeats other pages on the site.
• Few or no internal links pointing to it.
• A noindex, a robots.txt block for bingbot, or a canonical to another URL.
• The CDN serving Bingbot a challenge page instead of the content.
• A new domain with no links from elsewhere, which Bing may crawl slowly at first.

Bing Webmaster Tools' Site Scan runs an on-demand SEO audit of your site and flags many of these issues. Run it once on a new site.

A 30-minute setup checklist

• Site imported from Search Console or verified manually
• Sitemap submitted and showing a recent "Last read" date
• Sitemap listed in robots.txt
• One important URL checked in URL Inspection, live test passing
• IndexNow (or the API) wired into publishing, not both
• Site Scan run once, critical issues fixed

Written by the IndexerPal team. We build tools for URL and backlink indexing. IndexerPal includes Bing and Yandex alongside Google in every credit; see how it works.

This post looks at why linking pages stay out of the index, how to diagnose a specific link in a few seconds, and how to decide which links are worth any effort at all.

The page has to be in Google first

Google discovers links by crawling pages. If a linking page was never crawled, Google hasn't seen your link. If it was crawled but not indexed, Google decided the page wasn't worth keeping, which says something about how much weight anything on it is likely to carry.

So "is my backlink indexed?" really means "is the page that links to me indexed?" That's the page to check, not your own.

Why linking pages don't get indexed

Some link types index well and some rarely do. The reasons are the same ones that apply to any page.

The pattern: pages with real content, linked from other pages on the same site, index well. Pages that exist only to hold a link, or that look like many other pages, tend not to.

Diagnose one link in under a minute

Before spending money or time, check whether the linking page can be indexed at all, and whether your link is actually on it in a form Google can use. This script does both:

# check_backlink.py
import re
import sys
from urllib.parse import urlparse

import requests

# An honest user agent. Don't pretend to be Googlebot: many sites block
# fake Googlebot requests, and you'd be testing the block, not the page.
UA = "Mozilla/5.0 (compatible; backlink-check/1.0)"


def check(page_url: str, my_domain: str) -> list[str]:
    notes = []
    r = requests.get(page_url, headers={"User-Agent": UA}, timeout=30,
                     allow_redirects=True)
    if r.history:
        notes.append(f"redirects to {r.url}")
    if r.status_code != 200:
        notes.append(f"status {r.status_code}")
        return notes

    html = r.text
    if "noindex" in r.headers.get("X-Robots-Tag", "").lower():
        notes.append("X-Robots-Tag: noindex")
    if re.search(r'<meta[^>]+name=["\'](robots|googlebot)["\'][^>]+noindex', html, re.I):
        notes.append("meta robots noindex")

    canon = re.search(r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)', html, re.I)
    if canon and canon.group(1).rstrip("/") != r.url.rstrip("/"):
        notes.append(f"canonical points to {canon.group(1)}")

    links = re.findall(
        r'<a\b[^>]*href=["\']([^"\']*' + re.escape(my_domain) + r'[^"\']*)["\'][^>]*>',
        html, re.I)
    if not links:
        notes.append("link to your domain NOT in the raw HTML (JS-inserted or removed)")
    for tag in re.findall(r'<a\b[^>]*' + re.escape(my_domain) + r'[^>]*>', html, re.I):
        rel = re.search(r'rel=["\']([^"\']+)', tag, re.I)
        if rel:
            notes.append(f"link rel={rel.group(1)}")

    words = len(re.sub(r"<[^>]+>", " ", html).split())
    if words < 300:
        notes.append(f"thin page (~{words} words)")
    return notes or ["no blocking issue found"]


if __name__ == "__main__":
    domain = sys.argv[1]               # yoursite.com
    for line in sys.stdin:
        url = line.strip()
        if url:
            print(url, "|", "; ".join(check(url, domain)))

cat linking-pages.txt | python check_backlink.py yoursite.com

Also check robots.txt by hand for the host (https://host/robots.txt), since the script doesn't parse it. The word count is crude: it includes navigation text, so treat it as a warning, not a verdict.

What the results mean:

• noindex, a canonical elsewhere, or a robots.txt block: this page won't be indexed by any method. Ask for the link on a different page, or let it go.
• Link not in the raw HTML: it may be inserted by JavaScript. Google can render JavaScript, but a link that only appears after rendering is a weaker bet. If it's missing entirely, the link was removed.
• rel="nofollow", ugc or sponsored: Google treats these as hints rather than strict rules, but don't expect them to pass the same value as a plain link.
• No blocking issue, but not indexed: a discovery problem. This is the case worth working on.

Getting a clean page indexed

For pages that pass the checks above but still aren't in Google:

1. Ask the site owner for an internal link. A link to the guest post from the blog's home page, a category page or a related article is the strongest signal you can get on someone else's site.
2. Ask whether the page is in their sitemap. Many small blogs have sitemaps that exclude certain post types or haven't regenerated in months.
3. Give it a real reason to be crawled. Linking to the page from your own site, newsletter or social profiles gives crawlers another path to it.
4. Wait a fair amount of time. On a small blog, a few weeks is normal. Check again before doing anything else.
5. Use an indexing service for the ones that matter and still haven't moved. You can't request indexing in Search Console for a site you don't own, so this is the remaining option. IndexerPal is one such service: it works on any public URL, checks each one in Google afterwards, and its instant mode indexes pages in 2–5 minutes on average (IndexerPal's own measurement). It can't override a noindex or a thin page, which is why the checks come first.

Decide which links are worth the effort

Not every unindexed link deserves attention. A quick triage:

Also keep Google's link spam policies in mind. Buying links that pass ranking credit is against them whatever happens with indexing. Getting a page indexed doesn't change what kind of link it is. Google's most recent spam update on the Search Status Dashboard is the September 2026 spam update, which started on 24 Sep 2026 and took 13 days to roll out, so this is not a theoretical risk.

A monthly routine

• Export new linking pages from your backlink tool.
• Check which are in Google's index (a bulk checker saves hours here).
• Run the script above on the ones that aren't.
• Fix, request or drop each one using the tables above.
• Recheck the fixed ones next month.

Most of the value is in the second and third steps: finding out which links are actually missing and why, before spending anything on them.

Written by the IndexerPal team. We build tools for URL and backlink indexing. To get clean linking pages crawled and checked in Google, see the IndexerPal backlink indexer.

A sitemap built with a bit of care does two jobs: it helps Google find and recrawl the right pages, and it lets you see in Search Console exactly which groups of pages aren't getting indexed. This post covers both.

What Google says a sitemap is

From Google's sitemap guide:

• 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."
• Each sitemap file is limited to 50 MB uncompressed or 50,000 URLs. Above that, split it and optionally use a sitemap index file.
• Use fully qualified, absolute URLs. Google crawls them exactly as listed.
• Include the URLs you want to see in search results, meaning the canonical versions.
• Google ignores <priority> and <changefreq>.
• Google uses <lastmod> "if it's consistently and verifiably accurate", and it should reflect the last significant change: main content, structured data or links. A new copyright year doesn't count.

That last point is the one most sites get wrong.

Rule 1: only list URLs you want indexed

Every URL in the sitemap should pass all of these:

Parameter variations (?sort=price, ?utm_source=...) don't belong in a sitemap at all.

Rule 2: make lastmod true

Set lastmod from the date the content actually changed, not from the build time. If your CMS only stores one updated_at that changes on every save, add a separate content_updated_at that you only set when the body, title, structured data or links change.

A date-only value (2026-10-14) is fine. If you include a time, include the timezone (2026-10-14T09:12:00+00:00).

When lastmod is honest, it becomes useful: Google can see which pages changed since its last crawl and prioritize those.

Rule 3: split by page type

One giant file works, but splitting by type gives you a diagnostic tool for free. In Search Console's Page indexing report, you can filter by sitemap and see indexed vs not indexed for each one.

sitemap_index.xml
├── sitemap-pages.xml        (home, pricing, about, features)
├── sitemap-blog.xml         (articles)
├── sitemap-products-1.xml   (first 50,000 products)
├── sitemap-products-2.xml
└── sitemap-categories.xml

If 95% of sitemap-blog.xml is indexed and 30% of sitemap-categories.xml is, you know where to look without reading thousands of rows.

A generator that follows the rules

This Python script builds a sitemap index and type-based sitemaps from a database. Adapt the query to your schema.

# build_sitemaps.py
from datetime import timezone
from xml.sax.saxutils import escape
import gzip
import pathlib

BASE = "https://www.example.com"
OUT = pathlib.Path("public")
LIMIT = 50_000

QUERIES = {
    "pages": "select path, content_updated_at from pages where indexable",
    "blog": "select path, content_updated_at from posts where published and indexable",
    "products": "select path, content_updated_at from products where in_catalog and indexable",
}


def url_entry(path, updated):
    loc = escape(f"{BASE}{path}")
    lastmod = updated.astimezone(timezone.utc).strftime("%Y-%m-%d")
    return f"<url><loc>{loc}</loc><lastmod>{lastmod}</lastmod></url>"


def write(name, rows):
    body = "".join(url_entry(p, u) for p, u in rows)
    xml = ('<?xml version="1.0" encoding="UTF-8"?>'
           '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'
           f"{body}</urlset>")
    (OUT / name).write_bytes(gzip.compress(xml.encode("utf-8")))
    return max(u for _, u in rows)


def build(db):
    index = []
    for kind, sql in QUERIES.items():
        rows = db.execute(sql).fetchall()
        for n, i in enumerate(range(0, len(rows), LIMIT), start=1):
            chunk = rows[i:i + LIMIT]
            name = f"sitemap-{kind}-{n}.xml.gz"
            newest = write(name, chunk)
            index.append((name, newest))

    entries = "".join(
        f"<sitemap><loc>{BASE}/{name}</loc>"
        f"<lastmod>{newest.astimezone(timezone.utc):%Y-%m-%d}</lastmod></sitemap>"
        for name, newest in index
    )
    (OUT / "sitemap_index.xml").write_text(
        '<?xml version="1.0" encoding="UTF-8"?>'
        '<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'
        f"{entries}</sitemapindex>",
        encoding="utf-8",
    )

Notes on the choices:

• escape() handles & in URLs, which otherwise breaks the XML.
• Gzip is allowed; the 50 MB limit applies to the uncompressed size.
• The index's lastmod per file is the newest lastmod inside it, so Google can skip files that haven't changed.

Submit it in the places Google reads

Google lists three ways in its guide:

1. The Sitemaps report in Search Console. Submit sitemap_index.xml once; the child files appear under it.
2. robots.txt: Sitemap: https://www.example.com/sitemap_index.xml. Every crawler that reads robots.txt finds it.
3. The Search Console API, if you manage many properties.

The old "ping" URL is gone. Google deprecated the sitemap ping endpoint in 2023 and pointed to accurate lastmod values instead. Scripts that still call it get nothing back.

Audit the sitemap before Google does

Run this weekly, or in CI on a sample. It flags URLs that break Rule 1:

# audit_sitemap.py
import gzip
import random
import re
import sys
import xml.etree.ElementTree as ET

import requests

NS = {"s": "http://www.sitemaps.org/schemas/sitemap/0.9"}


def locs(url):
    raw = requests.get(url, timeout=30).content
    if url.endswith(".gz"):
        raw = gzip.decompress(raw)
    root = ET.fromstring(raw)
    if root.tag.endswith("sitemapindex"):
        for loc in root.findall("s:sitemap/s:loc", NS):
            yield from locs(loc.text.strip())
    else:
        for loc in root.findall("s:url/s:loc", NS):
            yield loc.text.strip()


def check(url):
    r = requests.get(url, allow_redirects=False, timeout=30,
                     headers={"User-Agent": "sitemap-audit"})
    problems = []
    if r.status_code != 200:
        problems.append(f"status {r.status_code}")
    if "noindex" in r.headers.get("X-Robots-Tag", "").lower():
        problems.append("X-Robots-Tag noindex")
    if re.search(r'<meta[^>]+name=["\']robots["\'][^>]+noindex', r.text, re.I):
        problems.append("meta noindex")
    m = re.search(r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)', r.text, re.I)
    if m and m.group(1).rstrip("/") != url.rstrip("/"):
        problems.append(f"canonical -> {m.group(1)}")
    return problems


if __name__ == "__main__":
    urls = list(locs(sys.argv[1]))
    sample = random.sample(urls, min(200, len(urls)))
    bad = {u: p for u in sample if (p := check(u))}
    for u, p in bad.items():
        print(u, "; ".join(p))
    print(f"{len(bad)} of {len(sample)} sampled URLs have problems")

The regexes are deliberately simple. They catch the common cases, not every HTML variant.

Reading the Sitemaps report

A sitemap gets URLs found. Whether they're indexed still depends on the pages themselves, which is where the per-sitemap view in the Page indexing report earns its keep.

Written by the IndexerPal team. We build tools for URL and backlink indexing. IndexerPal can import a sitemap directly and verifies each URL it sends in Google; see website indexing.

This is the plan we'd follow for any new site, from the day before launch to day 14. It assumes you own the site and can edit its code or settings. Google's own Search Essentials and SEO starter guide are the background reading.

Day 0: the launch-day check that saves weeks

The most common reason a new site isn't indexed after a month is a setting left over from staging. Before you announce anything, open these four things on the live domain:

1. https://yourdomain.com/robots.txt. It should not contain Disallow: / for all user agents. Staging sites often do.

2. The page source of the home page. Search for noindex. Many CMSs have a "discourage search engines" checkbox that adds it to every page.

3. The response headers: curl -sI https://yourdomain.com/. Look for X-Robots-Tag: noindex, which some hosts add to preview domains.

4. The canonical tag on a few pages. It should point to the live domain, not to staging. or a preview URL.

Also make sure http://, https://, www and non-www all redirect with a single 301 to the one version you want. Decide this now; changing it later means waiting for Google to process the move.

Day 1: tell Google and Bing the site exists

Search Console. Add a Domain property (verified with a DNS TXT record). It covers every subdomain and protocol in one place, so you won't miss data because Google picked a variant you didn't add.

Sitemap. Submit it in the Sitemaps report and add a Sitemap: line to robots.txt. On a new site, keep it to the pages you actually want found: home, main sections, key product or service pages, and published articles. Leave out tag archives, empty categories and search results.

URL Inspection. Inspect the home page, run "Test live URL", and if it passes, request indexing. Do the same for three to five of your most important pages. That's enough. Google's recrawl guide notes there's a quota and that repeated requests for the same URL don't speed things up. For the full picture of what the button does and why it sometimes fails, see our guide to Request Indexing in Search Console.

Bing Webmaster Tools. Use "Import from Google Search Console". It takes two minutes and verifies the site automatically.

Days 2 to 3: give crawlers a path in

Google mainly finds new URLs by following links from pages it already crawls. A sitemap helps, but a new domain with zero links from anywhere is easy to deprioritize.

Places that are crawled often and where a link to a new site is legitimate:

• Your own profiles: company page on LinkedIn, GitHub organization, social accounts.

• Partners, suppliers or clients who can mention you on a page that already exists.

• A launch post on a community where your audience actually is.

• Relevant, curated directories for your industry or location. Skip the mass-submission kind.

You're not building links for ranking here. You're making sure a crawler following ordinary links can reach your home page.

Days 3 to 5: fix internal linking before you add more pages

Check that every page you want indexed is linked from at least one other page with a normal <a href> link. Pages that only appear in the sitemap, or that are reachable only through a search box or a JavaScript menu that renders late, are the ones that stay "Discovered, currently not indexed".

A simple structure for a small site:

Day 7: first look at the data

By now Search Console usually has some data. Look at three places:

Page indexing report. Filter by your sitemap. Expect a mix: some pages indexed, some "Discovered, currently not indexed", maybe some "Crawled, currently not indexed". On a week-old domain, that's normal.

Crawl stats (Settings > Crawl stats). Confirm Googlebot is visiting and getting mostly 200 responses. A spike in 5xx or timeouts here means your hosting is the bottleneck.

URL Inspection for your key pages. If the home page still isn't indexed after a week, re-check the Day 0 list. A forgotten noindex is far more likely than a slow Google.

What not to do on day 7: request indexing for every page again, rewrite the whole site, or buy a batch of low-quality links. None of those make a new site more trustworthy.

Days 8 to 13: publish, link, wait

Use the second week to add the content that gives Google a reason to keep the site: pages that answer the questions your customers ask. Each new page should be linked from an existing one the day it goes live, and appear in the sitemap with an accurate lastmod.

If you publish regularly, set up IndexNow (it covers Bing, Yandex and others, though not Google) and keep the sitemap regenerating automatically.

Day 14: review

Make a short list:

Google's guide says crawling can take "anywhere from a few days to a few weeks", so a partly indexed site at day 14 isn't a failure. A site where nothing at all is indexed after two weeks almost always has a technical block. Go back to Day 0.

Where outside help fits

Most new sites get indexed with the steps above and some patience. An indexing service can help when a handful of clean, important pages are still waiting after the first week and the launch can't wait longer. It won't fix a noindex, a staging robots.txt or thin pages, so do the checks first.

Written by the IndexerPal team. We build tools for URL and backlink indexing. For new pages that need to be in Google sooner, see IndexerPal website indexing.

This guide covers what happens when you press it, the order of steps that avoids wasted requests, what each message means, and when another method is the better choice.

What the button actually does

From Google's recrawl guide:

• It asks Google to crawl one URL. It doesn't add the page to the index directly.
• "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all."
• "There's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster."
• You must be an owner or full user of the property, and you can't request indexing for URLs you don't manage.

Google doesn't publish the size of the quota. Treat it as a small daily allowance per property and spend it on pages that matter.

The four-step routine

Pressing the button first and reading later is how quota gets wasted. Use this order instead.

1. Inspect the URL. Paste the full URL, exactly as it appears in your sitemap and canonical tag, into the search bar at the top of Search Console. Trailing slashes, http vs https and www matter.

2. Read the indexed result. It shows what Google stored the last time it crawled: whether the URL is on Google, the last crawl date, and the canonical Google chose. If "Google-selected canonical" is a different URL, requesting indexing for this one won't help. Fix the canonical signals first.

3. Run "Test live URL". This fetches the page now. It tells you whether Google can crawl it today, whether noindex is present, and how the rendered HTML looks. If the live test shows a problem, the request will be rejected anyway.

4. Request indexing. Only once the live test passes. Then leave it alone for several days.

What each message means

Why requests fail or seem to do nothing

The page isn't indexable. noindex in the HTML or an X-Robots-Tag header, a robots.txt block, a 4xx or 5xx response, or a canonical pointing to another URL. The live test catches most of these. Check the response headers too, since an X-Robots-Tag: noindex added by a CDN or framework doesn't show in the page source.

Google crawled it and chose not to index it. The request worked: Google fetched the page. The status then often becomes "Crawled, currently not indexed", which is a judgement about the page, not a technical failure. Another request won't change that judgement.

You requested the wrong variant. You inspected https://example.com/page but your canonical says https://www.example.com/page/. Google treats them as different URLs.

It's too soon. Google's guide says crawling can take "anywhere from a few days to a few weeks". The indexed result in URL Inspection updates only after a new crawl is processed.

The page is on a site you don't own. You can't request indexing for it. This is the usual case for backlinks.

When to use it, and when not to

Good uses:

• A new page that matters (a launch, a pricing page, a key article) on an established site.
• A page you fixed after a noindex or error, to get the corrected version crawled.
• A significant update to an important page, such as new prices or a corrected fact.

Poor uses:

• Every new blog post on a site that publishes daily. Your sitemap and internal links already cover these.
• Hundreds of URLs after a migration. Submit the sitemap in the Sitemaps report and let Google work through it.
• Pages Google has crawled and decided not to index. Improve the page first.
• Pressing it again because nothing has happened after a day.

Request indexing vs Validate fix

The Page indexing report has its own Validate fix button. It's a different tool:

After fixing a sitewide issue, Validate fix is the right button, and you don't have to request each URL one by one.

A simple log for important requests

If your team requests indexing for important pages, keep a short log. It stops duplicate requests and tells you whether the button is helping.

date        url                                   reason             live test   result on day 3 / 7
2026-10-14  https://www.example.com/pricing/      new prices         pass        indexed / new version shown
2026-10-14  https://www.example.com/blog/launch/  new page           pass        not indexed / indexed
2026-10-15  https://www.example.com/docs/api/     removed noindex    pass        indexed / indexed

After a few weeks you'll have your own data on how long requests take on your site.

When you need more than the button

The button covers a few URLs on sites you've verified. Two situations fall outside it:

• More pages than the quota allows, for example a product launch with fifty pages that all need to be crawled the same day. A sitemap is the official route, at Google's pace.
• URLs on sites you don't own, such as backlinks, guest posts or listings. Search Console can't see or request them.

In both cases, outside indexing services exist. IndexerPal is one: its instant mode indexes pages in 2–5 minutes on average (IndexerPal's own measurement), and it checks each URL in Google afterwards. No service can make Google index a page it has decided not to keep, so the indexability checks above apply either way.

Written by the IndexerPal team. We build tools for URL and backlink indexing. For pages that need to be in Google quickly, see IndexerPal instant indexing.

Start with two questions

Before you pick a method, answer these:

1. Do you control the site? If it's verified in Search Console, you get Google's own answer. If it's someone else's site, such as a page carrying your backlink, you don't.

2. How many URLs? One URL by hand is fine. Fifty is tedious. Five thousand needs automation.

Method 1: the site: operator

Type site: plus the full URL into Google:

site:https://example.com/guides/setup

It works for any public URL and costs nothing. The catch is in Google's own wording: an indexed URL "can show up in search results for site: queries", but "it's not guaranteed" (source). Treat a hit as strong evidence and a miss as "unknown". It also doesn't scale. Google starts showing CAPTCHAs if you script it, and automated queries are against its terms.

Method 2: URL Inspection in Search Console

For a page on your own verified property, this is the answer to trust. Paste the URL into the top bar of Search Console and you get:

• whether the URL is on Google

• the last crawl date

• the canonical you declared and the one Google picked

• the reason, if it isn't indexed

Help page: URL Inspection tool. It's one URL at a time, and "Request indexing" in the same panel has a daily quota.

Method 3: the Page indexing report

Indexing > Pages in Search Console gives counts of indexed and non-indexed URLs, grouped by reason. Use it to spot trends, such as a sudden jump in "Duplicate without user-selected canonical" after a deploy. Two limits: example lists stop at 1,000 URLs per reason, and you can't search for a single URL. Google itself points you back to URL Inspection for individual pages (source).

Method 4: the URL Inspection API

The same data as Method 2, from code. Limits are 2,000 inspections per day and 600 per minute per property (usage limits). That's enough to monitor the pages that matter most on a mid-sized site every day.

A minimal script with a service account that you've added as a user on the property:

# pip install google-api-python-client google-auth
from google.oauth2 import service_account
from googleapiclient.discovery import build

SITE = "sc-domain:example.com"   # or "https://example.com/"
URLS = [
    "https://example.com/",
    "https://example.com/guides/setup",
]

creds = service_account.Credentials.from_service_account_file(
    "service-account.json",
    scopes=["https://www.googleapis.com/auth/webmasters.readonly"],
)
gsc = build("searchconsole", "v1", credentials=creds)

for url in URLS:
    res = gsc.urlInspection().index().inspect(
        body={"inspectionUrl": url, "siteUrl": SITE}
    ).execute()
    r = res["inspectionResult"]["indexStatusResult"]
    print(
        url,
        r.get("verdict"),          # PASS, NEUTRAL, FAIL
        r.get("coverageState"),    # e.g. "Submitted and indexed"
        r.get("lastCrawlTime"),
        r.get("googleCanonical"),
        sep=" | ",
    )

Field reference: urlInspection.index.inspect. Write the rows to a CSV each day and you have an indexing history you can diff after every release.

Two things trip people up. The siteUrl must match the property exactly (a Domain property uses the sc-domain: prefix). And the API only reads status. It doesn't request indexing.

Method 5: a bulk index checker

For URLs on sites you don't own, Search Console and its API can't help. A bulk checker takes a list, looks each URL up in Google and returns a status per row, usually as a CSV. It answers the same question as a site: search, at volume.

When you compare checkers, look at:

• Unit of billing: per URL or per batch of URLs. This changes the cost of a 5,000-link audit a lot.

• Batch size: how many URLs one run accepts.

• Export: a CSV with the exact URL you submitted, so you can join it back to your link list.

• Read-only: checking should not submit anything anywhere. Make sure the tool keeps those steps separate.

For your own pages, a checker is an outside view. URL Inspection still has the final word.

Reading the result without fooling yourself

Most "my page isn't indexed" reports we see come down to one of these:

You checked a different URL. http:// and https://, www and bare domain, trailing slash or not, uppercase in the path, a tracking parameter. Each is a distinct URL to Google. Normalize your list before you check it:

from urllib.parse import urlsplit, urlunsplit

def normalize(u: str) -> str:
    s = urlsplit(u.strip())
    return urlunsplit((s.scheme.lower(), s.netloc.lower(), s.path or "/", s.query, ""))

Then check the version that actually returns 200, not the one that redirects.

Google indexed the canonical instead. If the "Google-selected canonical" differs from your URL, the content is in the index under the other address. For a backlink, that can mean the indexed copy is a different page from the one carrying your link.

Indexed is not ranking. An indexed page is eligible to appear. It won't show for every query. To confirm presence, search for a distinctive sentence from the page in quotes.

The status changed. Pages drop out of the index and come back. A single check is a snapshot.

Not indexed was correct. Redirects, deliberate duplicates and pages with noindex are supposed to stay out. Filter them from your list before you count failures.

A backlink audit, step by step

1. Export the URLs of the pages that host your links, not your own URLs.

2. Normalize and dedupe them with a function like the one above.

3. Drop anything that redirects or returns 4xx or 5xx. A quick curl -o /dev/null -w "%{http_code}" loop does it.

4. Run the rest through a bulk index checker and save the CSV.

5. For each "not indexed" row, open the page. Confirm your link is still there and look at its rel value. Google treats nofollow, sponsored and ugc differently (qualify outbound links).

6. Decide per row: submit it to an indexer, ask the site owner to fix the page, or write it off.

7. Re-check new links about two weeks after they go live, then every one to three months for links that matter.

Quick answers

Does checking a URL get it indexed? No. Every method above only reads status. Submitting is a separate action.

Can I check Bing too? For your own site, yes, with the URL Inspection tool in Bing Webmaster Tools. Most bulk checkers focus on Google.

Written by the IndexerPal team. We build tools for URL and backlink indexing. To check up to 10,000 URLs in Google in one run, see the IndexerPal index checker.