When your schema points at the wrong domain

The canonical tag named one domain. The organisation markup named another. The same page carried two different regulator registration numbers. None of it is a ranking penalty — and all of it undermines exactly the signals that decide whether a source gets cited.

Why this matters more for regulated professions

For most sites, entity consistency is a refinement. For a solicitor, an accountant, a medical practice or a financial adviser, it is closer to load-bearing, for two reasons.

The first is that these fields are exactly where search and answer engines apply the most scrutiny before surfacing or citing a source. The chain that decides whether a page becomes an answer runs roughly: can it be crawled, can the content be extracted, can the page be understood, is the source relevant, is it trustworthy, does it answer the question, are there independent signals corroborating it. Identity claims feed the last three stages. When they contradict each other, the corroboration step has nothing to corroborate.

The second is regulatory. A registration number on a professional’s website is not decoration; it is how a member of the public verifies that the person is authorised to practise. Publishing two different ones is a compliance question before it is ever an SEO question.

What the audit found

1. Canonical and organisation markup named different domains

Every page declared a canonical URL on the firm’s current domain. The JSON-LD block on the same pages described the organisation with both its identifier and its url property set to a different domain — the firm’s legacy site, which was also still live.

Read literally, the page says: this document belongs here, and the organisation that publishes it lives somewhere else. Both statements are machine-readable, and they disagree. The likely outcome is not a penalty but a failure to consolidate: two partial entities, each holding a fraction of the firm’s reputation signals.

2. Two different regulator numbers on the same page

The author byline near the top of an article carried one registration number. The site footer and the structured data on the same page carried a different one. A reader who wanted to check the practitioner on the public register would get two different answers depending on where they looked.

This one is not primarily an optimisation issue, and it should not be presented to a client as one. It is a factual error about a regulated credential, sitting in public, and it is fixed first regardless of what it does to search performance.

3. Articles attributed to the organisation rather than to a person

The blog index stated that every piece is written and reviewed by the solicitor who does the work, and article pages carried the solicitor’s byline. Where a piece was in fact drafted by a specialist writer and reviewed by the solicitor, that arrangement was not expressed anywhere — not in the visible byline, and not in the markup.

The technically accurate structure, which also happens to be the stronger signal, separates the two roles:

• Author — a Person node for whoever wrote the text, with a stable identifier.
• Reviewer — a separate Person node for the qualified professional who verified it, with their credential and the date they checked it.
• Publisher — the Organization node, on the correct domain.

Collapsing all three into one claim loses the most valuable thing a professional site has: a named, qualified human standing behind the content. “Reviewed by a solicitor, registration number, on this date” is a stronger trust signal than “written by the firm”, and it is verifiable, which is the point.

The 12-point entity consistency audit

Run these against a single page, then against the homepage, then against one article. Contradictions almost always show up as a difference between two of them.

1. Canonical URL

   Does it name the domain the page is actually served from?

2. Organisation identifier

   Does it use the same domain as the canonical, on every page?

3. Organisation url property

   Same domain again. This is the one that is most often left behind after a domain change.

4. Logo and image URLs

   Hosted on the canonical domain, not the old one.

5. Contact details

   Email domain, phone numbers and addresses consistent between markup, footer and contact page.

6. Registration and licence numbers

   One number, everywhere. Cross-check against the public register, not against the site.

7. Author

   A Person node with a stable identifier, not the organisation, and not a free-text string.

8. Reviewer and review date

   Present on any page making professional claims, and matching the visible “last reviewed” line.

9. Publisher

   Resolves to the same organisation node as the identifier in check 2.

10. sameAs

    Professional register listing, directory profiles, social accounts. This is the corroboration step; without it the entity has only its own word.

11. hreflang cluster

    Every language version references every other, including itself, and all of them sit on the canonical domain.

12. Visible page matches the markup

    The byline, dates and credentials a reader sees are the ones in the structured data. A mismatch is worse than an omission.

Structured data is a set of claims about identity. If the claims disagree with each other, no amount of correct syntax makes them resolvable.

How to check it yourself in ten minutes

• View source on any article and search the raw HTML for canonical. Note the domain.
• Search the same source for “@id” and “url” inside the JSON-LD. Compare the domains against the one you just noted.
• Search for the registration number. Then search the footer for it separately. They should match, and both should match the public register.
• Search for “author”. If the value is an Organization rather than a Person, that is the finding.
• Run the page through Google’s Rich Results Test to confirm the markup parses, then read what it says the entity is — parsing successfully and describing the right thing are different tests.