Submit URL to Search Engines: What Actually Works Now

Most pages don't need to be submitted anywhere. Search engines find new and updated content primarily by crawling the links between pages and by reading XML sitemaps, and a page that's linked from somewhere a crawler already visits — with an entry in your sitemap — will typically get discovered and indexed on its own. If you're wondering whether you're supposed to manually hand each new URL to Google or Bing, the honest answer for the vast majority of pages is: no, not really.
Submission earns its keep in three narrower situations: a brand-new site with no inbound links yet, so there's nothing for a crawler to follow into it; a page you just published and would like looked at sooner than the next natural crawl pass; and a page you just fixed — a corrected canonical, a removed noindex tag, a repaired redirect — where you want the engine to re-evaluate it rather than wait for a routine recrawl. Outside those cases, submitting URLs is a habit left over from a much older, much smaller web, and it's worth understanding why before you spend time on it.
How search engines actually find pages
Crawling is the default discovery mechanism, and it works through links. A search engine's crawler starts from URLs it already knows, downloads each page, extracts every link on it, and adds any new links to a queue for a future visit. Repeat that across billions of pages and you get a web-scale process that finds new content without anyone announcing it — provided the new content is reachable by at least one link from somewhere the crawler already goes.
Sitemaps work alongside this rather than replacing it. An XML sitemap is a direct list of URLs you want crawled, optionally with a last-modified date, which gives the crawler a shortcut instead of relying purely on stumbling across a link. It doesn't force indexing — nothing does — but it removes any doubt about which URLs exist and roughly when they last changed.
How often a given page gets recrawled after that first discovery isn't fixed either. A homepage that changes daily and has a lot of authority tends to get revisited often; a low-traffic page buried deep in the site structure might sit unvisited for weeks. That's part of why a brand-new, thinly linked page can feel invisible even though nothing is technically broken — it's not being ignored on purpose, it's just low in the queue.
- Internal links from pages the crawler already visits
- External links from other sites
- XML sitemap entries
- URLs the crawler already knows about from a previous visit
When submitting a URL actually helps
The clearest case is a brand-new site. If a domain has zero inbound links and hasn't been in a sitemap a crawler has ever seen, there's genuinely nothing pulling a crawler toward it. In that specific situation, manually submitting the homepage, or a sitemap, gives the crawler its first entry point. Once that first page is indexed and linked to the rest of the site, the crawl can spread on its own through internal links.
The second case is timing. A newly published page will eventually get crawled through your sitemap and internal links regardless of what you do, but 'eventually' can be days on a low-authority site. If the content is time-sensitive — a news piece, a product launch, a correction to something already ranking — requesting a faster look is a reasonable use of the tool that exists for exactly that.
The third case is a fix. If a page was blocked, canonicalized elsewhere, or marked noindex, and you've corrected that, the crawler has no built-in reason to revisit it on its normal schedule; it already holds an old signal telling it not to bother. Nudging a recrawl after a fix like this is one of the few times a manual request changes the outcome, because it corrects stale information the crawler isn't otherwise motivated to update on its own.
The mechanisms that actually exist
Google's Search Console has a URL Inspection tool that checks a URL's current index status and includes a request-indexing option, which adds the URL to a priority crawl queue rather than indexing it on the spot. Bing Webmaster Tools has an equivalent URL submission feature, including a batch option for submitting a short list of URLs at once instead of one at a time.
XML sitemaps remain the real workhorse for anything beyond a single URL. Submit a sitemap once through Search Console or Bing Webmaster Tools, or simply reference it in robots.txt, and every URL in it, plus anything you add later, becomes visible to the crawler without further action. This is the mechanism that scales; individual URL submission does not.
IndexNow is a newer protocol, supported by Bing, Yandex, and a number of other participating engines, that lets a site push a notification the moment a URL is created, updated, or deleted, instead of waiting for a crawler to notice on its own. It works by hosting a small verification key file on your domain and then pinging an API endpoint with the changed URL, which any participating engine can pick up. Google does not participate in IndexNow, so submitting through it has no effect there — but for the engines that do support it, it's a genuine push mechanism rather than a request sitting in a queue.
And then there's internal linking, which isn't usually filed under 'submission' but functions as the most reliable version of it. A new page linked from your homepage, a category page, or a few related articles gets found the next time any of those pages are crawled — no tool, no queue, no waiting on a manual action to be processed.
What requesting indexing actually does — and what it doesn't
This is the part worth being precise about, because it's where most of the confusion sits. Clicking a request-indexing button submits a request. It adds the URL to a queue to be crawled sooner than it otherwise might be. It does not guarantee the page will be indexed — a crawler can visit a page and still decide not to index it. And it does not speed up ranking, because ranking happens after indexing and depends on entirely different signals: relevance, quality, links, and how the page compares to what's already ranking for that query.
It also doesn't stack. Requesting the same URL five times in one afternoon doesn't make it five times more likely to be indexed, or move it up the queue five times faster. Search engines rate-limit exactly this kind of repetition, and doing it repeatedly signals nothing except that someone keeps clicking the button. If a URL hasn't been indexed a day or two after a request, submitting it again is not the next step.
The next step, when a page genuinely won't index, is to stop treating it as a submission problem, because it isn't one. Submission gets a URL looked at. It has no influence over what the crawler decides once it looks.
If a page won't index, submission was never the problem
A page that gets crawled but stays out of the index almost always has one of a handful of causes, and none of them are fixed by resubmitting the URL.
The URL Inspection tool actually tells you which of these is happening — it reports the specific reason a URL is excluded, whether that's a duplicate-canonical decision, a 'crawled, currently not indexed' status, or a noindex directive. That diagnosis is the genuinely useful output of the tool; the request-indexing button is the least important part of it.
- A noindex tag, left in from a staging environment or a CMS default, telling the engine not to index the page
- A canonical tag pointing somewhere else, telling the engine this URL is a duplicate and another one is authoritative
- robots.txt blocking the page, or a resource it depends on, so the crawler can't fully render it
- Thin or near-duplicate content — a page that says little that isn't already said, better, on another URL on the same site or elsewhere
- Sitewide quality signals dragging an individual page down, particularly on sites with a large volume of low-value pages
Submission services and mass-submission tools
There's a category of service that promises to submit your site to hundreds of search engines for a fee, and software that automates the same pitch. It dates back to a much earlier web, when a handful of directories were curated by human editors and getting listed genuinely required asking. That era ended decades ago. Today, discovery runs on crawling and sitemaps, and the overwhelming majority of the engines on a five-hundred-engine list are either irrelevant, defunct, or not something any real user actually searches on.
Paying for this kind of service does nothing for the engines that actually send meaningful traffic, because neither operates on a manual-submission model these tools interact with. At best it's a wasted fee. At worst, the output is a pile of low-quality directory listings and link submissions that read as exactly the kind of manipulative link pattern a search engine's spam systems are built to discount — the opposite of what someone paying for this is trying to achieve. If a service's entire pitch is submission at scale, that pitch is the whole problem, and it has been for a very long time.
The tell is usually in the pricing structure: a one-time fee for a permanent, recurring benefit. Real discovery isn't a one-time event you pay to unlock — it's an ongoing byproduct of a crawlable site with a working sitemap and reasonable internal linking, which costs nothing beyond building the site correctly in the first place.
How to check whether a page is actually indexed
The fastest check is a site search: search for the exact URL using the site: operator in Google or Bing. If the page appears, it's indexed there; if it doesn't appear, it may not be, though this method is a rough signal rather than a precise one.
For a definitive answer, use the URL Inspection tool in Search Console, or the equivalent in Bing Webmaster Tools, which reports the exact index status and, when a page isn't indexed, the specific reason why. Beyond that, checking whether the page receives any organic impressions in Search Console's performance report over a couple of weeks is a good practical confirmation — an indexed page genuinely being served for relevant queries will usually show up there even before it ranks well.
- Run a site: search for the exact URL
- Check the index status in URL Inspection (Google) or the equivalent Bing tool
- Look for impressions on that URL in Search Console's performance report
- If none of these show anything after a reasonable wait, treat it as an indexing problem to diagnose, not a submission problem to repeat
Frequently asked questions
Do I need to submit every new page to Google?
No. A page linked from somewhere already crawled, with an entry in your sitemap, typically gets found and indexed without manual submission. Requesting indexing is useful for getting a first look sooner, not something every page requires.
Does requesting indexing help a page rank higher?
No. Requesting indexing only affects whether and when a page gets crawled and considered for the index. Ranking is decided afterward by relevance and quality signals that a submission request has no influence over.
What's the difference between a sitemap and requesting indexing?
A sitemap is a standing list of URLs that tells a crawler what exists on your site and roughly when it changed, and it covers your whole site continuously. Requesting indexing is a one-time nudge for a single URL, useful when you want that page looked at sooner than the routine crawl.
Is IndexNow the same as requesting indexing in Google?
No. IndexNow is a protocol that Bing, Yandex, and some other engines support for near-real-time notification of new or changed URLs. Google does not participate in IndexNow, so submitting through it has no effect on Google indexing.
Why would a page still not be indexed after I requested it?
Requesting indexing gets a page crawled sooner; it doesn't override the engine's decision about whether to index it. If a page isn't indexed after being crawled, the cause is almost always something else — a noindex tag, a canonical pointing elsewhere, thin content, or a crawl block — and that's what needs fixing.
Updated: September 14, 2026