You have reorganised the categories on your shop, and Google still shows the old addresses while several new pages are nowhere to be found. That gap is often normal. Publishing on your own site and processing by a search engine are two separate operations, running on two different clocks. What you do need to confirm is that the reorganisation has not created blocked access, orphaned pages or links pointing nowhere.
To follow an update properly, separate three things: what you published, what Google actually crawled, and which version it decided to keep. A single count of indexed pages cannot answer any of those questions on its own.
Most of the frustration around indexing comes from treating it as one switch, on or off. It is a chain, and each link can fail on its own.
What happens between publishing and a search result
The process Google describes has three stages: crawling, indexing and serving results. Not every page reaches every stage, and a page can stall at any one of them without anything appearing broken on your side.
| Stage | What happens | What it does not mean |
|---|---|---|
| Discovery and crawling | Google learns a URL, usually from a link or a sitemap, and may download its content. | Knowing an address is not the same as having fetched it. |
| Indexing | Google analyses the content, groups near-duplicate versions and may store the page. | A crawled page is not automatically an indexed page. |
| Serving | For a given query and context, Google selects which results to show. | An indexed page will not necessarily appear for the query you test. |
So Google can know an address without having crawled it, crawl a page without indexing it, or index a page that does not surface on the search you are running. A fresh crawl does not imply a better position either: recrawling and ranking are different questions.
Why refresh times vary so much
Google has to split finite resources between the URLs it already knows and the ones it keeps discovering. How often it comes back depends on several things, including how interesting it estimates your content to be and how well your server copes with being fetched. There is no guaranteed schedule, and no setting that buys one.
The current documentation on crawl budget separates crawl demand from available crawl capacity. That budget is not a fixed number of pages per visit. Detailed crawl-budget work is mainly relevant to very large sites, sites that change constantly, or sites with a genuine discovery problem.
Start instead with your important pages, your internal links, and the responses your server returns — including how quickly and consistently it answers. Publishing more often for the sake of it, or adding near-identical URLs, does nothing about access that is blocked. And any rule promising indexation "within a few hours" or "within three weeks" claims more precision than the evidence supports.
Track specific pages, not a single counter
In the Search Console page indexing report, read the reasons given for non-indexing and how they move over time. A rise in the number of known URLs can come from genuine new products — or from sort parameters, filter combinations and technical duplicates. Growth in that chart is not automatically good news.
Build a representative list instead: the home page, your main categories, a handful of products, anything published recently, and a few older addresses you have changed. Write down the outcome you expect for each one. That turns a vague impression into a check you can repeat, and it makes it obvious when Google has kept the wrong version of a page.
The URL inspection tool shows what Google already knows about an address and lets you test current access. Compare the last crawl date with your own modification date — that comparison alone explains a large share of pages that appear stuck outside the index. The live test checks certain aspects of access; it does not certify that the page will be indexed, or which canonical will end up being chosen.
A site: search can help you spot particular pages, but Google is explicit about its limits and its non-exhaustive nature. Traffic estimates from third-party tools are not a record of Google's index either; they are models, never designed to answer this question.
Should you block a site while you build it?
The right decision depends entirely on what is already public. For a new version of a site in preparation, work on a staging environment protected by authentication. You can then check content, forms and redirects without publishing half-finished experiments.
A public page carrying noindex is still reachable by anyone who knows the address. That directive keeps a page out of search results; it does not protect a confidential document or a test form. Google's technical requirements draw a clear line between content that is publicly accessible and content that requires a login.
Keep the existing site working during a redesign
If a site is already trading, avoid blocking its entire public version simply because you are preparing a new architecture. Keep the useful content live while the work happens, and plan the switchover for the moment your checks are complete, not the moment the design is signed off. Most of the risk in a redesign sits in that transition.
For new pages that are still incomplete, use drafts or the staging environment. Do not publish placeholder text on the live site on the grounds that it "gets SEO started". Opening pages gradually is reasonable when each one is finished and makes sense to a visitor who lands on it cold.
Check the settings on launch day
On the final domain, check public access, robots directives, canonicals, internal links and the sitemap. A noindex directive has to be crawlable to be read: blocking the crawl can stop it being processed at all. In the other direction, a noindex left behind on a page you want ranked quietly removes it from search.
Never copy staging settings straight through to the live site. This is a common way for a WordPress rebuild to go wrong, and it is invisible in the interface. Inspect the served HTML and the HTTP headers on the live domain after deployment, and confirm what is actually being sent rather than what the settings screen claims.
Supporting a category reorganisation
Changing a category label, or the text inside it, does not necessarily require changing its address. When the URL genuinely has to change, prepare a mapping between the old and the new page first. Google's guidance on site moves with URL changes recommends planning those correspondences and the redirects together, before anything goes live.
An old category may well have accumulated links and visits over the years. Do not send it to the home page by default when a more specific destination exists — that discards whatever relevance the original address had. Update your internal links at the same time, so they point directly at the final addresses rather than through a redirect chain.
If a piece of content has genuinely disappeared with no replacement, a 404 or 410 response can be the correct answer. It is not an error to be papered over with a redirect to something unrelated. Before removing the page, check which links still lead to it.
Signalling new and updated pages
A coherent sitemap helps flag the URLs you want discovered. According to Google's recommendations for building one, the lastmod date should reflect a real, significant change. Google ignores priority and changefreq values entirely, so editing them cannot impose a crawl rhythm.
Add links from relevant content as well. A category that is published but absent from the navigation and from every other page stays hard to discover, however carefully you list it in a file. The sitemap complements the structure of your site; it does not substitute for it.
After a substantial change you can request a recrawl through URL inspection. For a whole set of pages, use the sitemap instead. Repeating the request does not speed up processing and does not guarantee inclusion.
Removing an outdated result without confusing the tools
When an old page is still showing, check its current response and its last crawl date first. Google has to observe the change before it can act on it. For an urgent removal from the results of a site you control, the Search Console removals tool offers temporary hiding for roughly six months.
That hiding does not delete the page from your server and is not a permanent removal. A durable action on the content, its access or its indexing directives is still required. It is not a routine way to clear the old URLs left behind by a migration; used that way, it hides problems rather than fixing them.
Once you are live, follow your priority pages and the anomalies you have genuinely observed, rather than watching a total. The outcome worth aiming for is a stable public version, consistent addresses and accessible content. Indexing then gradually comes to reflect the choices you made.
Common questions
Does Google update a page as soon as I publish it?
No. The change is visible on your site immediately; Google then has to discover or recrawl the address and process it. Compare your modification date with the last known crawl date to see where the delay sits.
Should I stop Google reaching the site during a redesign?
Protect the work-in-progress version on a separate environment instead. If a public site is already trading, blocking it entirely can interrupt its visibility while the new version is still not ready to replace it.
Is a rise in the number of indexed pages always a good sign?
No. Check which URLs are involved. Useful products, technical duplicates and sort variants all inflate the same counter. What matters is that the right version of your important pages is the one indexed.
Can a sitemap force a crawl date?
No. It flags URLs and can carry a modification date for genuine changes. Google decides how to treat them and ignores the priority and changefreq values altogether.
What should I do with a category whose address has changed?
Redirect it to the page that genuinely takes over its content or its role, then update your internal links to point at the new address directly. Where no change is needed, keep the existing URL.
Does the Search Console removals tool delete a page permanently?
No. It hides the result temporarily, generally for around six months. A lasting removal also requires an appropriate action on the content itself, on who can access it, or on its indexing directives.