---
name: check-schema-connects-to-all-verified-profiles
description: "Check that each profile link points to the right person or firm."
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check schema connects to all verified profiles

Your site should link to the right person or firm. This guide helps you check the data that tells search tools who you are. Start with public pages whose owner you can prove.

**The path:** Verified identity → Right schema node → Relevant profiles → Source and tool checks.

**Use this when:** A site’s structured identity data is being added, changed or audited. Schema is machine-readable information about the page; sameAs links identify that same person or organization elsewhere.

## Inputs
- The exact site and visible person/business identity, with a verified public-profile list and evidence for each owner.
- The served structured data, supported schema source and edit scope. A plugin is optional; existing custom code may be the correct source.
- An appropriate structured-data validator and Google’s Rich Results Test where a supported feature is involved.
- An issue log that separates syntax, entity identity, profile access and Google feature eligibility.

## First-run prompt

> Inspect the supplied site’s visible identity, served schema and verified public-profile inventory. Map sameAs URLs to the correct entity nodes, fix authorized exact-source issues, and record facts, syntax, access limitations and Google feature checks separately.

## Steps
1. Write down which entity each page describes: a person, company, local business or several linked entities. Give each existing node its correct identity; do not combine the owner’s personal profiles and company profiles into one list by convenience.
2. Inspect the served schema and its @id links. Find the applicable Person, Organization or LocalBusiness node and its sameAs values. Record duplicate/conflicting nodes generated by separate plugins or code.
3. For each sameAs URL, check that it unambiguously identifies that same entity. A person’s LinkedIn profile can belong on that person’s node; the company’s Facebook page belongs on the company node. A business listing is not automatically the individual’s identity page.
4. Compare against the applicable verified public-profile inventory. Include relevant identity references missing from that node, using canonical URLs. “All verified profiles” means the right approved identity set, not every private account, social post or page linked anywhere on the site.
5. Inspect redirects and visible profile identity where accessible. A login wall or rate limit is an access limitation, not proof the profile is deleted. If identity cannot be checked, keep that specific URL unknown and request the actual owner evidence.
6. Update the supported schema source within scope. Keep identity consistent with visible page content. Do not manufacture a profile or relationship to fill a schema field, and do not install another SEO plugin solely to edit a graph that already has a supported source.
7. Validate syntax and applicable vocabulary, then test Google-supported features where relevant. A generic Person or Organization graph may not produce a rich-result feature. Zero tool errors does not certify that the identities are true or guarantee a Knowledge Panel.
8. Recheck the served canonical graph and save the exact node-to-profile map, evidence and remaining gaps. Hand off only the result of this check, not a claimed completed full-site audit.

## Definition of done (QA checklist)

- [ ] Each profile maps to the same actual entity as its schema node.
- [ ] Applicable verified public profiles and @id relationships are recorded without personal/company conflation.
- [ ] Source facts, syntax and Google feature eligibility have separate results.
- [ ] The canonical served graph matches authorized edits, with access-limited targets marked unknown.
- [ ] No new profile, relationship or Knowledge Panel result is invented.

## Example(s)

**Fictional teaching example — no structured data was changed.** Alex owns Maple Cycle. The sample Person node points to Alex’s personal profile; the Organization node points to Maple Cycle’s company page.

An old graph puts the shop’s business listing in Alex’s sameAs array. The proposed correction moves that identity reference to the business node and preserves the supported relationship between Alex and the shop. It does not delete the business profile from the site.

A clean syntax check plus “no supported rich results detected” can still be consistent with useful identity markup. The reviewer must verify the facts separately.

## Handoff and Content Factory context

The technical owner receives the served identity map and exact unresolved profile evidence. [Verify Person schema](https://local-service-spotlight.github.io/task-library/?task=verify-person-schema-with-sameas-links#task-verify-person-schema-with-sameas-links) is appropriate only when a real Person node is in scope; business profiles stay with the correct business entity.

This is a supporting quality check for the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. This check does not automatically execute all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

Run at launch and when verified identities, profiles or schema sources change. Do not create profile-monitoring schedules without an existing defined job.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 3 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Canonical article: https://blitzmetrics.com/website-qa-audit
- Exact task: [Check schema connects to all verified profiles](https://local-service-spotlight.github.io/task-library/?task=check-schema-connects-to-all-verified-profiles#task-check-schema-connects-to-all-verified-profiles)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Website QA Audit](https://blitzmetrics.com/website-qa-audit/)
- [Entity linking](https://blitzmetrics.com/entity-linking/)
- [Schema.org sameAs](https://schema.org/sameAs)
- [Google structured-data introduction](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- The actual public-profile identity proof, schema source and canonical validation evidence require the project.