How to Request Indexing in Google Search Console
This is the button people press when something is not working. It almost never helps. There are three situations where it genuinely does. Knowing those saves you from the loop of submitting the same page every morning and wondering why nothing changes.
It Is A Request, Not An Instruction
Requesting indexing asks Google to look at one address sooner than it otherwise would. It does not oblige anybody to store the page, it does not override a decision already taken about it and it has no effect on how well the page competes afterwards. It is a queue rather than a switch.
Why the wording matters. The expectation is wrong.
People press it expecting a result. What it produces is a slightly earlier visit, which only helps if a visit was the thing standing in the way.
What it is genuinely useful for. Impatience about new work.
Where a page is fine and simply has not been seen yet, asking shortens the wait. That is a real and modest benefit. It is also the whole legitimate use.
What it cannot do. Change a judgement.
Where Google has already fetched the page and decided not to keep it, another visit reaches the same conclusion. Nothing about the page has changed, so nothing about the answer does.
Why that is not obvious. The two states look identical.
From the outside, a page never visited and a page visited and declined both look like a page that is not appearing. The inspection tool tells you which you have. That determines whether requesting is worth doing at all.
What this page is really about. Not pressing it.
Three cases where you should, one large case where it is pointless and what to do instead. That last one is where the actual work sits.
When It Genuinely Helps
Three situations. This is not an abbreviated list for the sake of brevity. It is the whole set. If your situation is not one of these, requesting is not the answer.
A brand new page. Nothing has seen it yet.
Published this morning, linked from somewhere sensible and not yet visited. Asking brings the visit forward, which matters when the page is timely.
An important page that has just changed substantially. Not a typo fix.
A rewrite, a significant addition or a correction to something misleading. Where the stored version is now wrong in a way that costs you, asking for a fresh look is reasonable.
A page fixed after a problem. The strongest case.
You have found why a page was not being stored, changed the thing responsible and want the assessment redone. This is requesting used properly, as the last step rather than the first.
What all three have in common. Something changed first.
In every legitimate case there is a new state of affairs for Google to assess. Requesting without a change is asking somebody to reread the same page and reach a different conclusion.
How many times to ask. Once.
Make the request, note the date and move on. Block four covers what happens to people who do not.
When It Will Not Help
Where a page is not being stored for a reason, requesting will not change that. The reason is almost always one of three things, none of which is affected by asking again.
Quality. The commonest and least welcome.
The page was fetched and judged not worth keeping. That is a verdict on the content rather than a technical failure. No submission overturns a verdict.
Duplication. Another page is doing this job.
Where the page is substantially the same as another one, Google keeps one and treats the rest as versions of it. Requesting the copy simply confirms that decision.
A blocking instruction. Your own site said no.
Something on the page or in the site's rules preventing storage. This one is genuinely worth fixing and it is a technical change rather than a request.
How to tell which you have. Look at the reason.
The reporting gives one for every excluded page. Fixing indexing errors covers what the two most common messages mean and why they need opposite responses.
What to do about a quality verdict. Improve or remove.
Make the page genuinely better, merge it into something stronger or accept that it does not need to exist. Those are the three real options.
Requesting Repeatedly Does Nothing
Submitting the same page every day does not improve the odds, shorten the wait or move you up any queue. It is one of the more common habits we find people have developed. It consumes attention that could go somewhere useful.
Why people do it. It feels like pressure.
Nothing else about the situation is within your control, so the one available action gets repeated. That is a completely understandable response and it has no effect.
What the second request adds. Nothing.
The page is unchanged since the first one. Asking again is asking the same question about the same page and expecting a different answer.
What the twentieth adds. Still nothing.
There is no accumulation. Twenty requests are not twenty times more persuasive than one. Nothing about frequency signals importance.
What to do with the impulse. Change something instead.
If you find yourself wanting to press it again, that is the signal to go and look at why the page is not being kept. The impulse is right and the action is wrong.
What we tell clients. Once, then measure.
One request, the date recorded, then a look in a few weeks. Anything more frequent is watching a kettle.
Do Not Use It At Scale
This is a per page action with a small limit attached, so it was never designed for working through a list. A business with hundreds of unstored pages is looking at a structural problem. Submitting them individually would take weeks and change nothing.
Why the limit exists. It is not a bulk facility.
It is there for the occasional urgent page rather than as a mechanism for getting a site indexed. We are not quoting a daily figure, because those numbers change and it is enough to know the allowance is small.
What large numbers of unstored pages mean. Something else.
Either the site publishes more than its standing supports. Or a large share of the pages are too similar to each other. Or something is blocking them wholesale. All three are site level problems.
The uncomfortable version. Fewer pages.
Frequently the answer is that the site needs fewer and better pages rather than more attention paid to the ones it has. Our material on pruning covers making that decision properly.
What to do at scale instead. Fix the system.
Improve internal linking, submit an accurate sitemap, remove the near duplicates and give the remaining pages a reason to be kept. That works on all of them at once.
Where to start. The gap.
Compare pages published against pages stored, which the page indexing report shows, then work on the reasons rather than the addresses.
What To Do Instead
Three things genuinely influence whether a page gets stored. None of them is a button. They are slower than requesting and they work, which is the trade.
Link to it internally. The strongest thing you control.
A page linked from your main navigation or from a page that already performs well is a page your site is declaring important. A page nothing points at is a page you have implied does not matter.
Include it in the sitemap. Quiet and useful.
It should be there anyway if you consider the page worth storing. It should not be there if you do not. Our sitemap guide covers why contradicting yourself weakens the whole file.
Make it worth keeping. The one that decides it.
Something on the page that does not exist elsewhere, either on your site or on anybody else's. Storage is a judgement about worth, so this is the lever that actually moves it.
Then be patient. Properly patient.
A genuine improvement takes effect at the next visit and possibly the one after. Weeks rather than days, plus considerably longer on a site Google visits rarely.
How to tell it worked. Inspect, do not guess.
Check what Google holds for the address rather than searching for it manually. Everything sits on the Google Search Console guide.
The button is
not the problem.
The page
is.
A page Google has already looked at and declined will be declined again, however many times it is submitted. What changes the answer is finding the reason, which is nearly always quality, duplication or an instruction on your own site, then dealing with that.
How we approach a page that will not index:
If the answer is that the page does not need to exist, we will say so rather than optimise it.
Every guide.
One tool.
Getting set up and verified, using the reports properly, the performance and indexing data, finding what is broken, finding what is being passed over and turning any of it into work worth doing.
