The stand is booked, the catalogue is printed, and the product page went live four weeks ago. It is not in Google. Nobody told you, because nothing in the process is designed to tell you — silence is what failure looks like at this stage.
Publishing a page and having it appear in search results are separated by three distinct events, each of which can fail quietly. Google has to learn the address exists. A crawler has to fetch it. The fetched page has to be judged worth keeping. There is no notification when any of those steps does not happen, and no error page to inspect.
For a company exhibiting in Cologne, this matters more than it does for a business with an even trading year. A page for a permanent product line that arrives late is an inconvenience. A page for a fair that opens on a fixed date is either present or worthless.
How an address reaches Google at all
Google does not index websites. It indexes addresses, and it learns about them through a small number of channels. Anything that appears in none of them is invisible regardless of how good the page is.
- An internal link from a page already known. The strongest channel by a considerable margin. It communicates existence and relative importance at the same time, which no other channel does.
- An external reference. A listing in the exhibitor directory of the fair itself is frequently the fastest route available to a foreign company, and it costs nothing beyond filling in a form you have already paid for.
- An XML sitemap. Necessary and weak. An address that appears only in a sitemap has, by implication, not been considered important enough to link to from anywhere on the site.
- An explicit submission. The most direct way to shorten discovery. It replaces waiting with telling, and it does nothing about the two steps that follow.
The most common failure is prosaic. A new page is created inside a language folder, added to the sitemap, and linked from nowhere. It sits at the end of a chain that starts nowhere, and it is treated accordingly. Before considering anything technical, open the home page and try to click your way to the new page. If you cannot, the sitemap entry is the only thing holding it up.
Crawl budget, and whether it applies to you
The term is used far more often than it is relevant. Crawl budget is not a quota that can be purchased; it is the outcome of two things — how much load your servers absorb without slowing, and how much interest Google has shown in your content historically. Both move, and the second depends on whether crawling you has previously been worthwhile.
Four situations where the budget genuinely bites
For a normal corporate site it is almost never the cause. For these four it frequently is.
- Catalogue sites with faceted navigation. Filters, sort orders and session parameters turn four hundred real pages into forty thousand addresses. Crawlers spend their time on near-identical variants and reach the new page last.
- One page per market, generated automatically. An exporter with the same specification sheet published for nineteen countries has nineteen pages that differ by a currency symbol. A portion of them will simply not be kept.
- Slow response under load. If the server is slow, Google reduces its own rate. This is politeness rather than punishment, and the effect is identical: fewer pages fetched.
- Sites that changed address structure recently. After a migration, a large share of crawl activity goes into confirming redirects rather than discovering new content, sometimes for months.
For the typical exhibitor site — a few dozen product pages, a company section and a fair landing page — the cause is essentially never crawl budget. It is thin internal linking or text that could belong to any supplier in the category. That is better news than it sounds, because neither requires infrastructure work.
Submitting is not indexing
This is where most of the money is wasted. Submitting an address means Google now knows it exists. It does not mean the page will be added to the index, and it certainly does not mean the page will be there by a particular date.
So why submit at all? Because it removes the first of the three steps from the critical path. Instead of waiting for a crawler to encounter the address through a link, the address becomes known immediately. In practice that saves days and sometimes weeks — and for a page tied to a fixed date, those days decide the outcome.
Shortens discovery
The address is known at once rather than found eventually. Changes to existing pages are announced the same way.
- Useful for date-bound pages
- Useful after price or availability changes
Replace substance
It does not compensate for a thin page, absent links or a near-duplicate of another page on the same site.
- Thin pages stay out
- Duplicates are still consolidated
The Indexing Hub and its actual limits
The Indexing Hub inside the Semalt workspace manages this step: it accepts addresses, submits them, records what happens afterwards and shows where something is stuck. Its capacities are fixed, and knowing them before drawing up a schedule is the difference between a plan and a wish.
| Capability | Intended for | Hard limit |
|---|---|---|
| Single-URL tracker | Targeted submission of pages that matter | daily budget of 1,000 URLs per account |
| Bulk submission | Relaunch or large structural change | 10,000 URLs per batch |
| Sitemap submission | File or address, resolved recursively | three levels deep, 1,000 sitemaps per job |
| IndexNow relay | Notifying GoogleBot and BingBot | notification only, never acceptance |
The daily figure of a thousand addresses per account is the one that governs planning. A relaunch of a three-thousand-page catalogue takes three days of submissions, not three hours. Teams that overlook this arrive at their deadline short, conclude that the content was at fault, and rewrite pages that were never the problem.
Two of the six figures above deserve a second look, because they are the ones that quietly break schedules. The first is the three-level recursion limit for sitemaps. A site that hands over an index file pointing at further index files pointing at sitemap sets is already at the boundary; anything deeper is not fully resolved. This arrangement is more common than it should be in catalogue systems that have grown by acquisition, and it is invisible until the day somebody notices that a whole product family never appeared.
The second is the pairing of two concurrent jobs with twenty queued. For routine operation that is generous. On relaunch day, when somebody wants to push every section simultaneously, it is the point at which the plan stops matching reality. Staggering by section costs nothing and keeps each log interpretable, which matters more than raw throughput once something goes wrong. The queue state is visible in the Semalt workspace alongside the per-URL log, so a stalled job is apparent rather than assumed.
The per-URL log is the part that earns its keep
Submission is the trivial half. The valuable half is the record of what followed: when a bot arrived, with what status, and, if it failed, with what detail. Counters for submitted, discovered and failed addresses run alongside.
Reading the log correctly
One symptom, four causes, four completely different pieces of work.
- No bot visit after several days. The notification arrived; the interest did not. The cause is nearly always internal linking. Link the page from two existing pages rather than submitting it again.
- Bot visit with an error status. A crawler arrived and hit an obstacle — a redirect chain, a timeout, an accidental block. This is the most tractable category, because the cause is named for you.
- Successful visit, no indexing. Google looked and declined. That is an editorial verdict: too thin, too close to another page, no distinct purpose. Resubmitting changes nothing.
- Indexed, then dropped. Common for date-bound pages between events. The page sat unchanged and unvisited for months and was demoted. Annual updating prevents this far more reliably than resubmission.
Without a log there is only the observation that a page is not indexed, followed by guesswork. With one, the distinction between "link it", "fix it" and "rewrite it" is immediate — and those three tasks differ by an order of magnitude in cost.
Four patterns specific to exhibitors
Working with companies that exhibit in Cologne, the same four situations recur often enough to be worth naming.
The page built three weeks out
Late, unlinked, submitted once. It arrives after the fair, if at all.
- Twelve weeks is the workable minimum
- Link it from the home page, not only the sitemap
A new page every year
A fresh address for each edition, with the previous year left online competing for the same terms.
- Keep one address and update it annually
- Or redirect the old one deliberately
Two languages, one text
The German page is a machine translation of the English one, with no distinct content of its own.
- Consolidation is likely, not certain
- Distinct examples beat translated sentences
The microsite nobody links to
A separate domain built for one campaign, with no connection to the main site in either direction.
- Starts with no history at all
- A subfolder would have inherited some
All four are structural problems presenting as indexing problems, which is precisely why repeated submission does not resolve them. The structural review belongs in technical SEO, and the question of which page should own which term belongs in keyword research — before anything is submitted at all.
There is a fifth pattern that appears only in the second year, and it is the most expensive one to discover late: the fair landing page that was deleted after the event. It ranked, it earned links from the exhibitor directory and from trade press, and then somebody removed it in the January clear-out because the event was over. The address returns a not-found status, the accumulated links point at nothing, and the following year the process starts from zero again. Redirecting is almost always better than deleting; keeping and updating is better than both.
The order that works
Sequence matters more than tooling. Submitting before the structure exists spends daily budget on addresses that will be declined anyway.
| Step | Action | When to move on |
|---|---|---|
| 1. Link | Link the new page from at least two existing pages | immediately |
| 2. Sitemap | Add the address, regenerate the file | same day |
| 3. Submit | Send through the Hub with IndexNow relay active | same day |
| 4. Read the log | Bot visit, status, error detail | after two to seven days |
| 5. Respond | Link, repair or rewrite according to the picture | on the finding |
For larger changes the sitemap route takes over: hand over a file or an address, nested files are resolved up to three levels deep, up to a thousand sitemaps per job, two jobs running with twenty more queued. Staggering jobs by section — products first, then locations, then editorial — keeps the logs readable and uses the same capacity considerably better than submitting everything at once. The resulting index coverage sits next to clicks and positions in the Semalt dashboard, so a page that never made it in is visible before further work is spent on it.
Why this connects to everything else
Indexing is not a separate project. It is the point at which all other work becomes visible or does not. A rewritten page that is never indexed is worth exactly as much as an unwritten one, and a link built to an unindexed page is effort spent on nothing.
That is why submission tools belong beside campaign automation and analytics rather than in a separate application. In My SEO, term selection, link building, page recommendations and index status sit next to one another, and the project timeline records new links with the referring domain's rating and traffic as they appear. The practical benefit is unglamorous: you find out that a page was never indexed before you commission three more links pointing at it.
Local presence signals interact with all of this more than most exporters expect, and the practical checks for a German address, service area and contact details are covered under local SEO.
Check index status in the dashboard
Frequently asked questions
How long does indexing take for a new page?
Anywhere from a few hours to several weeks, and the range is real rather than evasive. Two factors dominate: how well the page is linked internally, and how often Google already visits the site. A new page on a frequently updated domain is often indexed the next day; the same page on a site untouched for two years can take weeks.
Does submitting the same URL repeatedly help?
No. A submission is a notification, not an application that becomes more persuasive through repetition. If several days pass with no bot visit, the cause is almost always linking. Link the page from two existing pages and wait a week — that works considerably more reliably than a second submission.
What does IndexNow add?
It notifies GoogleBot and BingBot of changes without waiting for a crawler to arrive on its own. That is particularly useful for pages that change often — prices, availability, event details. As with any notification, it accelerates discovery and compels nothing.
Our German pages are translations. Will they be indexed?
Frequently yes, but with less independent standing than pages written for the market. A translated page competes against pages written by people who know how German buyers describe the problem, and it usually loses on phrasing rather than on quality. The pragmatic route is to translate the technical material and write the commercial pages — the ones meant to produce enquiries — from scratch.
We have three thousand pages and a limit of a thousand a day. Where do we start?
In order of commercial value, not address order. Pages intended to generate enquiries first, then overviews and category pages, then archive and legal material. Three days spent in that order produce a noticeably better outcome than three days spent in whatever order the export happened to be in.
Can a page that was indexed disappear again?
Yes, and it is normal. Pages with no traffic, no internal links and no changes get demoted. For event pages this happens routinely between editions. The remedy is not resubmission but keeping the page alive: update it once a year, link to it from current articles, and give it content that has a purpose outside the fair week.
