The German subsidiary requested four new pages in March. They went live in September, inside the group content system, in a language folder nothing links to. By December none of them were in Google, and the group's digital team concluded that German search is difficult.
German search is not difficult. What is difficult is publishing into a structure designed to keep nineteen country sites consistent, where a subsidiary controls the words on a page and almost nothing else — not the address, not the navigation, not whether anything links to the result.
The three events that stand between publication and findability are separate, and a group content system can obstruct each of them independently. Recognising which one is blocked saves a subsidiary from rewriting text that was never the obstacle.
Where a country site loses its pages
An address becomes known to a search engine through a small number of channels, and a language folder inside a group system typically has access to the weakest of them.
| Channel | Strength | Typical situation in a group system |
|---|---|---|
| Internal link from a known page | Strongest by a wide margin | Country navigation is generated by script; no link in the delivered markup |
| External reference | Strong, and outside the group's control | Trade directory entries usually point at the group domain, not the country page |
| XML sitemap | Necessary and weak | Often one group-wide file where the country pages sit at position 40,000 |
| Explicit submission | Shortens discovery only | The one channel a subsidiary can actually operate itself |
The first row explains most cases. If the country navigation is built client-side, the pages behind it are not linked at all as far as a crawler is concerned. For a visitor the menu is exemplary. For discovery it does not exist, and no amount of German copywriting changes that.
Whether crawl capacity is really your problem
The term is used far more often than it applies. Crawl capacity is not a quota that can be purchased. It results from two things: how much load the servers absorb without slowing, and how much interest the content has generated historically. Both move, and the second depends on whether crawling this domain has previously been worthwhile.
Where capacity genuinely constrains a group domain
On a sixty-page country site, never. On a group domain carrying nineteen markets, frequently.
- One product catalogue replicated per market. The same specification sheet published nineteen times with a currency symbol and a phone number exchanged. A share of those pages will simply not be retained, and nobody can predict which share.
- Configurator parameters in the address. Filters, sort orders and session identifiers turn four hundred real articles into forty thousand addresses. Crawlers then spend their allowance on variants.
- Slow response under load. If the server answers slowly, the crawler reduces its own rate. That is courtesy rather than penalty, and the effect is identical: fewer pages fetched.
- Recent migration between group platforms. For months afterwards, a large part of the activity goes into confirming redirects instead of discovering anything new. Country pages published during that window are the ones that disappear.
The first row is the specifically international failure. Nineteen near-identical specification pages are treated as one page with variants, and the retained variant is not necessarily the German one. A subsidiary then observes that its pages are missing and concludes the market is hostile, when the actual cause sits in the group publishing model.
Submitting an address is not indexing
This is where the most money is wasted, usually on services that promise something nobody can deliver.
The value lies elsewhere and is still substantial: submission removes the first of the three stages from the critical path. Rather than waiting for a crawler to arrive via a link that may not exist, the address becomes known at once. For a subsidiary that cannot fix the navigation because it belongs to the group, this is frequently the only lever available — which makes it worth using well rather than dismissing.
What a subsidiary controls
The words on the page, the submission of the address, and whether anything external points at it.
- Trade directory entries pointing at the country page
- Submission and log reading
What belongs to the group
Address structure, navigation markup, the sitemap, server response times.
- Raise as a documented request
- With a log extract attached, not an opinion
What the Indexing Hub does and where it stops
The Indexing Hub in the Semalt workspace administers this step: it accepts addresses, passes them on, records what follows and shows where something has stalled. Its capacities are fixed and belong in a schedule before anybody promises a date to head office.
Two of those figures regularly break a schedule. The nesting limit of three levels catches group sitemaps in particular: an index file pointing at further index files pointing at sets is already at the boundary, and anything deeper is not fully resolved. In a group that has grown by acquisition, this arrangement is the norm rather than the exception, and it stays invisible until an entire market's pages turn out to be missing.
The second is the daily allowance of a thousand addresses. A country site with three thousand pages needs three days, not three hours. Plan accordingly and the deadline holds; overlook it and the subsidiary explains a shortfall it did not cause.
The per-address log is the argument
Handing an address over is the easy part; the record of what happened next is where the value sits. Each entry carries the time a crawler called, the status it returned and, where it failed, the reason given. Three running totals accompany it — how many addresses were sent, how many were found, how many failed.
| What the log shows | What it means | What to do |
|---|---|---|
| No visit after several days | The notification arrived; the interest did not | Obtain links — internal if possible, external if not |
| Visit with an error status | A technical obstacle: redirect chain, timeout, accidental block | Send the detail to the group platform team as a ticket |
| Visit, then no indexing | An editorial verdict: too thin, too close to a sister page | Rewrite with the local specifics that the template lacks |
| Indexed, then dropped | Months without changes, links or visits | Update annually and link from current material |
For a subsidiary the log has a second use that is arguably more valuable than the first. A request to a group platform team carries very differently when it arrives as "the German pages are not performing" than when it arrives as a log extract showing thirty addresses with a redirect-chain status and a timestamp. The first is an opinion from a country office. The second is a defect report, and defect reports get scheduled.
Turning a local complaint into a platform ticket
The same finding, written two ways. Only one of them gets scheduled.
- Name the affected addresses, not the market. Thirty URLs listed in a file are a defect. "The German site" is a territory with an opinion, and territories with opinions wait behind roadmap items.
- Quote the returned status verbatim. A redirect chain, a timeout value, a blocking directive — these are things a platform engineer can reproduce in ten minutes. A description of symptoms is not.
- State the commercial consequence in one line. Not "we lose visibility" but the number of capability pages involved and the enquiry volume those pages historically carried.
- Propose the smallest possible fix. Rendering the country menu as plain links in the delivered markup is a smaller request than redesigning the navigation, and it solves the same problem.
Subsidiaries frequently underestimate how far this goes. A group platform team is not indifferent to search performance; it is buried under requests that cannot be assessed. A file of thirty addresses with statuses attached converts an unassessable request into a scheduled one, and it does so without anybody at the country office having to argue about priorities.
Four situations specific to country sites
Nineteen markets, one text
The same specification page translated for every country, with no local content of its own.
- Consolidation is likely, not certain
- Local references beat translated sentences
The campaign microsite
A separate domain built for one trade fair, connected to the main site in neither direction.
- Starts with no history whatsoever
- A subfolder would have inherited some
Data sheets behind a login
The technical figures buyers search for sit exclusively inside a gated asset library.
- Publish the key figures as text
- Keep the file itself gated if required
The discontinued product line
No longer supplied, still online, competing with its successor for the same terms.
- Redirect to the successor deliberately
- Deleting loses the accumulated references
All four present as indexing problems and none of them are. Repeated submission therefore achieves nothing. Which structure can carry the market at all belongs in technical SEO; which page should own which capability term is settled beforehand during keyword research, and how the local material is structured around it in our content strategy.
The third card is worth a separate remark, because gated asset libraries are close to universal in engineering groups. Restricting the file itself is a defensible commercial decision. Restricting the figures inside it is not, because a purchasing engineer will not register in order to find out whether a supplier is even relevant — they will move to the next result whose figures are readable. Publishing tolerance class, batch range and material list as body text on an open page, while leaving the drawing and the full certificate behind the login, satisfies both requirements at once. Where those figures should sit in the page structure is exactly what the page recommendations in the workspace point at, since they are generated against the pages that already exist.
The order that actually works
Sequence decides more than tooling. Submitting before anything links to the page spends the daily allowance on addresses that will be declined regardless.
- Obtain a link first. Two internal links from pages that themselves receive visits. Where the group navigation makes that impossible, an entry in a trade directory pointing at the country page is the practical substitute.
- Then the sitemap. Confirm the address is in the file that is actually served, not in a staging copy. On group platforms these are not always the same file.
- Then submit. One submission through the Hub with the IndexNow relay active. Once, not repeatedly.
- Read the log after two to seven days. Earlier is pointless; later loses the connection to whatever was changed.
- Respond according to the finding. Link, escalate as a ticket, or rewrite — three tasks that differ by an order of magnitude in cost, chosen from evidence rather than from instinct.
Where a whole section changes at once, the sitemap route is the appropriate one. A file or a URL is handed over, nesting is followed to a depth of three, a single job accepts up to a thousand sitemap files, two jobs run concurrently and a further twenty wait their turn. Splitting the work by section rather than firing everything at once keeps the individual logs interpretable — which is precisely what is needed on the day something fails and somebody has to say which product family is missing. Coverage then appears next to the click and position figures in the Semalt dashboard.
Why this is not a separate project
Index coverage is the point at which every other piece of work becomes visible or does not. A newly written capability page that stays out performs exactly as well as an unwritten one. A link built to a page that was never retained is paid work with no return.
Keeping the submission tooling in the same place as campaign control and reporting follows directly from that. Inside My SEO the term list, the placement activity, the page suggestions and the coverage status share one screen, with every placement carrying the rating and traffic of the site it sits on. The advantage is prosaic: a country office finds out that a page never entered the index before it orders three placements aimed at that page.
Check index coverage for the country site
Questions from country marketing
How long should indexing take for a new page?
Anything from the same afternoon to a month and a half, and that spread is real rather than evasive. It comes down to two things: whether anything on the site points at the page, and how regularly the domain gets crawled in the first place. On a busy group domain a new page frequently appears overnight; the identical page dropped into a language folder with no inbound links may wait weeks or never surface.
The group navigation is script-generated. What can we do locally?
Two things without waiting for a platform change. First, obtain external references pointing directly at the country pages — trade directories, association listings, supplier registers — because those bypass the internal navigation entirely. Second, cross-link the country pages to each other from body text, which is content rather than template and therefore usually within local control. Neither is a substitute for a proper menu; both work while you wait for one.
Our German pages are translations. Will they be retained?
Usually they are retained, though they carry less weight than material written in the market. The opposing pages were drafted by people who share the vocabulary of a German purchasing department, and that difference shows in phrasing rather than in substance. What works in practice is a split: the corporate and heritage material gets translated, while the handful of pages meant to generate enquiries is written locally, borrowing wording straight from incoming requests.
Is it worth submitting the same address twice?
No. A submission is a notification, not an application that gains weight through repetition. If several days pass with no crawler visit, the cause is almost always that nothing links to the page. Secure two links first and give it seven days; that produces a result far more dependably than resubmitting, and it leaves you with something to act on either way.
How do we get the group platform team to act?
By sending evidence rather than an assessment. A log extract listing affected addresses, the status returned, the timestamp and the number of pages involved reads as a defect report. "German search is underperforming" reads as a country office asking for attention. The first gets a ticket number; the second gets a reply thanking you for the feedback.
Can a page that was indexed disappear again?
Yes, and on country sites it is common. Pages with no visits, no internal links and no changes get demoted. Resubmission does not address it; maintenance does. Update once a year, link from current material, and add the technical figures whenever the specification changes — three habits that cost an hour a year and prevent the entire cycle from starting again.