What asking for indexing actually does

What the request is

A queue entry. It tells the engine you believe something has changed and asks for a fresh look sooner than scheduled.

The decision about storing the page is unaffected. A thin page requested ten times remains a thin page.

There is a daily limit per property, which exists because the request is a favor rather than a control.

The queue is shared across everybody using it, so your request competes with a great many others. That is another reason a genuine change is worth flagging and a routine one is not.

The queue is shared with everybody using it, which is another reason a genuine change is worth flagging and a routine one is not.

When it genuinely helps

A brand new important page you do not want waiting a fortnight. A page you just fixed after finding a problem.

A page that was accidentally excluded and is now corrected. These are real changes worth flagging.

In each case, once. Then leave it alone for a week.

It is also worth using after fixing something site wide, on one representative page. If that page recovers, the fix worked, and you can leave the rest to the normal schedule.

It is also useful after a site-wide fix, on one representative page. If that page recovers, the fix worked and the rest can follow the normal schedule.

When it does nothing

Requesting the same unchanged page repeatedly. Requesting a page the engine has already declined to store.

Requesting every page of a site one at a time, which is a long afternoon with no measurable effect.

It also does nothing for ranking. It is about being looked at, not about being preferred.

It will not rescue a page the engine has judged too thin. The request is answered, the page is looked at again, and the same decision is made. The page has to change first.

• Requesting the same unchanged page again
• Requesting a page the engine has already declined to store
• Requesting every page of a site one at a time
• Requesting a page that is blocked or carries a noindex instruction
• Requesting in the hope of improving a ranking
• Requesting a page nothing links to

The better tool for many pages

A sitemap. It lists everything, carries a last modified date for each address, and is checked regularly without being asked.

Keep it generated from what actually exists rather than maintained by hand, so it cannot drift.

For a site that publishes often, an accurate sitemap does more than any number of individual requests.

A sitemap generated from what actually exists does more than any number of individual requests — see sitemaps that actually help.

The faster route on other engines

Bing and several other engines accept direct notification when a page changes, which is close to immediate.

It also feeds engines that use Bing's index, so one submission covers several destinations.

Google does not participate in that scheme, so the two routes are complementary rather than alternatives.

Setting expectations

Hours to days for an established site. Longer for a new domain with little history.

If a page is still missing after a fortnight with no reason given, the problem is usually the page rather than the queue.

Every page written by Website Builder Studio is checked before anything publishes and enters a sitemap rebuilt from what exists, so discovery is handled without any manual requests.

If a page matters commercially, link it prominently from a page that already performs. That does more for how quickly it is found than any submission, because it changes how important the page looks.

If a page matters commercially, link it prominently from a page that already performs. That does more for discovery than any submission.

A sensible routine

Publish. Confirm the page is in the sitemap. Request indexing once for anything commercially important.

Check back in a week with the inspection tool rather than by searching.

That is the entire workflow, and anything more elaborate is effort spent where it cannot help.