Open a corporate site and you are looking at two machines at once. The first is the one this magazine writes about: pages, titles, crawl paths, the public surface a search engine reads. The second is invisible to a crawler: the enterprise systems that decide what a client portal shows, which order statuses exist and which documents a logged-in visitor can pull. Most visibility analyses stop at the first machine. On a real company domain, the second one writes a good part of what the first one serves.
Why do enterprise pages behave differently from classic marketing sites?
A marketing page is written; a portal page is computed. The catalogue entry, the delivery status, the invoice history a client sees are assembled at request time from records that live in a system nobody in the web team administers. In a large part of the corporate world that system speaks one language: the ERP, and very often the SAP estate behind it. For a sight of what sits on that side, the Italian ABAP development guide keeps a working window open: internal tables, ALV reports, transport orders, the Data Dictionary. Reading it explains why a portal page can be slow, duplicated or half-empty without anyone in marketing having touched a template. For the vocabulary itself, the encyclopaedia entry on the language is a fair map of how deep that layer goes.
The consequence for visibility is structural. A crawler meets the output, not the process. When the output is wrong, thin or inconsistent, the fix rarely starts in the SEO toolset. It starts in a change request, a transport, a release window. The publishing rhythm a small publisher controls directly is, on an enterprise domain, a queue somebody else owns.
Where does the content of a corporate portal really come from?
Three sources, roughly. The CMS holds the editorial layer: pages written to be read, the part an audit recognises. The business system holds the record layer: products, prices, statuses, documents, rendered through components the editorial team configures but does not write. And the integration layer holds the plumbing between them, where content is transformed, filtered and occasionally lost. A symptom on the public site can originate at any of the three, and each has a different owner, a different release cycle and a different definition of done.
This is why enterprise sites accumulate the pathologies our technical guide lists at industrial scale: parameterised duplicates, orphaned statuses, staging subdomains left crawlable. None of it is negligence. It is the by-product of a system doing its actual job, keeping the records straight, while the public surface inherits whatever the records happen to look like.
How do you diagnose a corporate site problem that is not an SEO problem?
The tell is a defect that persists across every fix the web team ships. Titles rewritten, templates cleaned, sitemaps corrected, and the anomaly returns with the next data push. That pattern means the source of truth is upstream, and the honest move is to trace the field, not the page: which system emits the value, through which interface, on which refresh cycle. The habit is the same one we argue for in the note on testing an SEO claim before acting on it: state what you believe the cause is, then find the smallest observation that would prove you wrong.
For the analyst outside the firewall, the lesson is more modest. When you audit an enterprise domain, mark the pages whose content is computed rather than written, and treat their defects as symptoms of a pipeline. The ranking problem you can see may be a records problem you cannot. Saying so plainly, in the report, is worth more than another round of metadata.
The desk’s position: a corporate site is a publication with a factory attached. The factory has its own logic, its own custodians and its own pace. Visibility work that ignores it polishes the shopfront while the storeroom decides what goes on the shelf.