Your network has eleven offices and eleven websites, all built from the same template, all describing the same services with the city name swapped. Search engines treat that as one page with eleven variants and keep whichever they like. It is rarely the one you would have chosen.
Agency networks in shipping accumulate domains the way they accumulate offices: one per location, each with its own history, each maintained by whoever happened to be available. The arrangement is operationally sensible and produces a specific and predictable problem — a large number of near-identical addresses competing with one another under the same ownership.
Between publishing a page and having it found sit three separate events. None of them announces itself when it fails, and in a network of this shape the same one fails almost every time.
Eleven offices, one page
A template that generates a services page for each location produces eleven addresses whose text differs by a city name, a phone number and a photograph. To a reader in Singapore that is helpful localisation. To an indexing system it is one document with eleven copies, and it will retain a subset — chosen on criteria that have nothing to do with which office you want enquiries to reach.
The remedy is not more submission. It is giving each location page something that only that location can say: which terminals it clears at, which trades it actually handles, which authorisations the local entity holds, which languages the desk answers in. Those facts exist in every office and appear on almost no office page, because the template was designed to be filled quickly rather than distinctly.
When your own operations software consumes the capacity
The second source is larger and less visible. Shipment tracking, quotation views, booking references and filter combinations in a rate tool all generate addresses that are opened exactly once by exactly one person. Crawlers do not know that. They follow links.
What is inflating the number of addresses
A site of sixty pages is untouched by any of this. An operator running live systems will recognise all four.
- Tracking and reference pages. One address per shipment, week after week, frequently listed in the sitemap because the sitemap is generated from the database. Nothing here should ever be indexed and most of it is submitted anyway.
- Rate and schedule tools with parameters. Origin, destination, equipment type and sort order in the address turn a handful of real pages into tens of thousands of combinations.
- One template per office. Eleven near-identical service pages, and in networks with country subdomains the same eleven again under a different host.
- Slow response when crawled in bulk. Where pages are assembled per request instead of ahead of time, heavy crawling slows the server and the crawler backs off out of politeness. Well-mannered, and the result is still that fewer pages get read.
Where the daily allowance is being consumed by material that should never have entered the queue, the counters in the workspace show it within a week — sent figures far above anything the site could plausibly need. The first item does more damage than the other three combined and is the cheapest to fix. Excluding tracking and reference views from indexing and removing them from the sitemap is a configuration change made by whoever administers the operations software — not a marketing project, not a content decision, and not something that requires anybody's approval beyond a ticket.
Submitting is not indexing
The benefit is real and narrowly bounded: one of the three stages drops out, because discovery is no longer required. In a network whose own address factory is consuming the available crawl capacity, that is frequently the only lever available until the configuration changes — which makes it worth operating properly rather than dismissing as ineffective.
What the commercial side controls
Submission, what goes in the sitemap, cross-links written into body text, and the distinct facts on each office page.
- No deployment needed
- Produces evidence for the next step
What the platform controls
Excluding tracking views, canonical handling across office pages, response times under load.
- Raise with a log extract attached
- Small changes, disproportionate effect
The Indexing Hub and the figures that govern a plan
The Indexing Hub in the Semalt workspace exists precisely for this step: it accepts a list of addresses, passes them along, keeps the responses, and shows where progress has halted. Its limits are fixed quantities, which means any timetable has to be built around them and not despite them.
| Capability | Use in an agency network | Where it stops |
|---|---|---|
| Tracking one address at a time | the ten or twelve pages that should bring enquiries | daily ceiling of a thousand per account |
| Submitting in bulk | moving platforms, or reworking how addresses are formed | ten thousand per batch, no more |
| Passing over sitemaps | automatically generated sets, often one per location | nesting three deep, a thousand files in one job |
| Relaying through IndexNow | altered sailing schedules, fresh permits, service bulletins | it informs; it does not commit anybody to anything |
The nesting limit catches networks specifically. A sitemap index pointing at per-office indexes pointing at per-section files is already at the boundary, and anything below it is not fully resolved. The symptom is one office disappearing entirely while the other ten behave normally — which gets diagnosed as a local problem and is not one.
Reading the per-address log
Submission itself is trivial. What earns its keep is the account of what happened afterwards: the moment a crawler arrived, the status it gave back, and where it failed, the stated cause. Three counters run alongside — how many went out, how many were picked up, how many did not.
| What the log shows | What it means | Who acts on it |
|---|---|---|
| Days pass with no crawler at all | The address is on file, but no page leads there | Commercial — cross-links in body text, no deploy |
| A crawler arrived and got an error | Chained redirects, a timeout, or a rule denying access | Systems — as a ticket with the status attached |
| Visit, then not retained | Too thin, or indistinguishable from a sister office page | The local office — facts only it can supply |
| Retained, then dropped | Months without changes, links or traffic | Commercial — annual revision, link from current material |
The third column is what makes this useful in a network. It converts a vague observation into an assignment, and two of the four rows never reach the systems team at all. The third row in particular is the one that has to go to the office rather than to headquarters, because nobody at headquarters knows which terminals the Piraeus desk actually clears at.
Three responsibilities, only one of which is technical
Agreeing this once removes most of the delay that keeps network sites stuck for years.
- What the platform generates belongs to the systems team. Which addresses the operations software creates, what reaches the sitemap, which sections are excluded from indexing. Purely technical questions carrying no customer-facing statement.
- What each office page says belongs to that office. Terminals served, trades handled, authorisations held, languages answered in. Headquarters cannot supply these and an agency certainly cannot invent them.
- Linking and submission belong to whoever runs the site. Passing an address to a service is a notification, not a publication — yet in most networks this step ends up in a ticket queue where it simply waits.
Writing those three sentences down is the most effective organisational step available here. Without them, every change — however trivial — is routed to the systems team by default, because nobody wants to be the person who decided it did not need to go there. With them, two thirds of the work completes within days, and the systems team receives a short list of addresses with statuses instead of a general complaint about visibility.
Four situations specific to networks
Eleven offices, one text
The same service description with a city name exchanged, and nothing that only one office could say.
- Consolidation is likely, not certain
- Local facts beat local photographs
The staging or legacy host
A superseded platform that never went offline, sitting on a subdomain — sometimes with a sitemap of its own and links pointing at it.
- A single directive shuts it out
- Worth re-checking every quarter
Schedules and tariffs behind a login
The figures buyers search for sit exclusively inside the customer portal.
- Publish the structure, not the rates
- Keep the file gated if required
The discontinued service page
Taken down when the lane closed, and with it every link that trade portals and forums had built over the years.
- Point it at whatever replaced it
- Deletion throws the accumulated links away
All four present as coverage failures and none of them are, which is precisely why resubmitting achieves nothing in any of them. Whether the structure can support this market at all sits within technical SEO; which page carries which lane term is answered during keyword research, and how the local material is organised around it in our content strategy.
The order that works
- Exclude first. Tracking, reference and parameter views removed from indexing and from the sitemap. One configuration step that multiplies the effect of everything after it.
- Differentiate second. Give each office page five sentences that could not appear on any other office page. Without this, submission and linking are wasted on documents that will be consolidated anyway.
- Then obtain links. Two from pages that themselves receive traffic. In this trade the strongest available and least used source is the network's own news and service-notice pages.
- Sitemap next. Check the entry exists in the file the server actually delivers. On platforms that build their sitemaps automatically, that is not always the same file the developers see.
- Submission after that, a single time. One pass through the Hub with the relay switched on. Sending it again changes nothing whatsoever.
- Look at the log between day two and day seven. Before that there is nothing to read; after that the finding can no longer be tied to the change that caused it.
For a change that touches an entire section, hand over the sitemap instead: either the file or its address, with nesting followed three levels down, a thousand files accepted per job, two jobs live and another twenty queued. Do this office by office rather than all at once and every log stays readable — which is exactly what you need on the day a single location vanishes from results. Whatever coverage results shows up in the Semalt dashboard next to the traffic and position figures, so nobody commissions work for a page the index never took.
Why this is not a separate workstream
Everything that went in beforehand becomes visible at this one point or does not. A newly written lane page that stays out contributes nothing — the same as a page that was never written. A citation earned for an address the index does not hold is effort with no return.
That is why the submission tooling sits with campaign control and reporting rather than in a separate application. My SEO puts the term list, the placements, the model's suggestions for existing pages and the coverage status onto a single screen, with each placement annotated by the strength and traffic of the site hosting it. The advantage is mundane and worth money: a missing page is spotted before anybody orders links pointing at it.
Check coverage across the network in the dashboard
Questions from network and office management
Our tracking system generates tens of thousands of addresses. What now?
Not more submission — less permission. Tracking, reference and parameter views belong excluded from indexing and removed from the sitemap, so that crawl activity lands on the pages meant to produce enquiries. It is a configuration change rather than a project, and it has a larger effect than any other single measure in this area.
Should each office have its own domain?
Rarely, at least not for search reasons. Separate domains start with none of the accumulated history of the main one, and eleven of them divide whatever authority exists across eleven starting points. Where separate legal entities require separate presences, that is a commercial decision to be made knowingly — and it then makes the differentiation of each office page more important rather than less.
Our office pages are near-identical. How much has to change?
Less than most people fear and more than a photograph. Five sentences per page that could not be moved elsewhere unchanged: the terminals actually served, the trades handled, the authorisations the local entity holds, the languages the desk answers in, and a named contact. Each office can supply that in ten minutes; the difficulty is collecting eleven sets of ten minutes.
Must we open the customer portal?
No, and that is not the question. Negotiated rates belong behind the login. What can be public is the structure: which surcharges exist, how they are calculated, which unit applies, what transit ranges are typical. That is what gets searched — the figure itself almost never is, because everybody knows it is negotiated.
Does resubmitting the same address help?
No. A submission is a notification and does not gain weight through repetition. If a week passes with no crawler visit, the cause is nearly always that nothing links to the page. Put two links in place from pages that themselves see traffic and wait seven days — that works considerably better and leaves you with something to act on either way.
How do we get the systems team to prioritise this?
Hand over proof instead of an opinion. Export the affected addresses with their returned status and the time of each attempt: that document is a bug report and gets logged as one. A sentence about search performance is a request for consideration and gets answered with thanks. Same underlying observation, and only the first version reaches a development cycle.