DEV Community: Joseph Anady

Building a real-time, offline drum trainer in the browser with Web Audio and Web MIDI

Joseph Anady — Fri, 19 Jun 2026 02:43:52 +0000

A few months ago I set out to build a drum-practice app that runs entirely in the browser, grades your timing in real time, and works offline. It became GrooveSteps, a free drum trainer. Here is how the core pieces actually work, in case you are building anything rhythm or audio related on the web.

Scheduling audio with a look-ahead clock

The naive approach to a metronome, setInterval firing a sound, drifts badly because timers are not sample-accurate. The fix is the pattern Chris Wilson described years ago: a look-ahead scheduler. A setInterval wakes up every ~25 ms, looks a small window into the future, and schedules any notes that fall inside it directly on the Web Audio clock with AudioContext.currentTime and oscillator.start(time).

const lookahead = 0.1; // seconds
function scheduler() {
  while (nextNoteTime < audioCtx.currentTime + lookahead) {
    scheduleNote(nextNoteTime);
    nextNoteTime += 60.0 / bpm / stepsPerBeat;
  }
}
setInterval(scheduler, 25);

Because the timing lives on the audio hardware clock, the click stays rock-steady even when the main thread is busy.

Scoring timing in real time

Every scheduled beat registers an expected hit time. When the player taps, I compare the input time to the nearest expected time and bucket it: perfect within 30 ms, good within 60 ms, ok within 100 ms, otherwise a miss. That yields an accuracy percentage, a combo counter, and a letter grade. The interesting wrinkle is latency calibration: browsers and Bluetooth add unpredictable output delay, so a short tap test measures the player's average signed error once and stores an offset that is subtracted on every later judgment.

Talking to a real drum kit with Web MIDI

This surprised people the most: an actual electronic drum kit plugs in over USB and plays the app. The Web MIDI API exposes inputs, and a General MIDI note map turns pad hits into the right sounds.

const access = await navigator.requestMIDIAccess();
for (const input of access.inputs.values()) {
  input.onmidimessage = (e) => {
    const [status, note, velocity] = e.data;
    if ((status & 0xf0) === 0x90 && velocity > 0) triggerPad(GM_MAP[note]);
  };
}

Making it installable and offline

A service worker precaches the shell and samples, and the manifest makes it installable, so the trainer runs as an offline Progressive Web App on a phone with no connection. The one gotcha worth repeating: never cache non-OK responses, or you can poison the offline cache with a 404.

Takeaways

Use a look-ahead scheduler, never raw timers, for anything musical.
Calibrate latency once instead of fighting it forever.
Web MIDI is underused and genuinely fun for instrument apps.

If you want to poke at the result, the drum trainer, rudiments, and play-along grooves are all free at groovesteps.com, and I wrote up the rhythm terms in a drum and music glossary. Happy to answer questions about the audio engine.

SEFERIM AGI — ThatAIGuyCore: a golden-ratio cognitive substrate (open source)

Joseph Anady — Sat, 06 Jun 2026 00:32:26 +0000

The old AI research folder on my desktop turned out to contain a complete, self-contained mathematical specification — 69 equations across 13 systems — for a golden-ratio cognitive substrate I call SEFERIM / ThatAIGuyCore. So I built it for real.

What it is

SEFERIM treats cognition as a 16-dimensional meta-state evolving under sixteen coupled "cognitive families," all governed by the golden ratio φ. Every dynamic is a named, documented equation — not an opaque weight matrix.

Open source (MIT): https://github.com/Janady13/seferim-core
Interactive docs + live demos: https://thataiguy.org/core/
Zero-dependency JavaScript. Runs in the browser and Node.

The 13 systems

Constants (φ, δ, τ) → golden basis ψ_k → the 16 G¹⁶ families → meta-state core with golden-ratio momentum + stability gating → a free-energy-style objective Ω → DNA holographic memory → a 5000-gate binary substrate → an 88-agent neural brain → a 374-dimensional consciousness binding field → a lattice engine with Hebbian plasticity → federation cross-talk across agents.

import { MetaState, DNAMemory, NeuralBrain } from "seferim-core";

const mind = new MetaState({ init: new Array(16).fill(0.1) });
const out  = mind.step({ dx_norm: 0.3, ed_error: 0.1, utility: 0.6, stability: 0.8 });
console.log(out.state, "Omega =", out.omega);

Built on real math (honestly)

It synthesizes the Free Energy Principle (Friston), information theory (Shannon; Cover & Thomas), holographic/vector-symbolic memory, Hebbian plasticity, and swarm consensus. I documented the lineage precisely rather than overclaim — e.g. the memory is a golden-ratio frequency-domain VSA inspired by (not a literal copy of) Plate's HRR, and the constant δ = 0.013618 is empirical, not 1/φ³.

The reference implementation ships with 42 fidelity tests, including the canonical FNV-1a hash vectors.

Read the full 69-equation reference and try the live demos at thataiguy.org/core.

I built a browser drum machine you can play with a real MIDI kit (no install, no samples)

Joseph Anady — Thu, 04 Jun 2026 20:19:10 +0000

A free, no-signup browser drum machine that runs entirely client side, and that you can play live with a real electronic drum kit over USB. No samples, no downloads, no account.

Play it here: https://jennysdrumsteps.thatwebhostingguy.com/app/

Every drum is synthesized, not sampled

There are no audio files. Every voice (kick, snare, hats, toms, cymbals, a full Latin percussion set) is built from oscillators, noise, and envelopes through the Web Audio API at runtime. A kick is a pitch swept sine into a fast amplitude envelope. A snare is filtered noise plus a body tone. Cymbals are banks of inharmonic partials shaped with a long decay. Because it is all synthesis, the whole kit ships as code, loads instantly, and every hit can respond to velocity.

Timing comes from a lookahead scheduler

You cannot trust setTimeout for musical timing. The pattern player uses the well known lookahead pattern: a timer wakes up often, looks a short window into the future, and schedules every note that falls inside that window directly on the Web Audio clock. The audio clock is sample accurate, so the groove stays tight even when the main thread is busy. Open and closed hats share a choke group so a closed hat cuts an open one, the way a real hi hat does.

Plug in a real electronic kit with Web MIDI

This is my favorite part. Click Connect Drum Kit, allow MIDI access, and the site listens to your physical e kit. It maps the full General MIDI percussion range to the synthesized voices and passes velocity through, so soft ghost notes stay quiet and rim shots crack. The handler reads note on messages, treats note on with velocity zero as note off the way many kits send it, and accepts every channel so it just works.

Web MIDI is supported in Chrome and Edge on desktop and Chrome on Android. Safari and iOS do not implement it, so the app detects support on load and falls back cleanly to the on screen pads and the computer keyboard.

Accessible by design

The pads are real buttons with labels, the FAQ is native details and summary, and the whole thing works with zero framework and near zero blocking JavaScript. It is fast on a phone and usable from the keyboard.

If you have a drum kit gathering dust, plug it in and have fun: https://jennysdrumsteps.thatwebhostingguy.com/app/

I build web apps and engine optimization at ThatDevPro and ThatDeveloperGuy.

Schema.org sameAs is not a backlink field (and what it costs you)

Joseph Anady — Thu, 04 Jun 2026 03:46:45 +0000

sameAs is the most misused property in structured data. I've watched it tank a
site's trust signals, and the cause is almost always the same: someone treated it
as a place to stuff links.

Here is the rule, stated plainly: sameAs is for the entity's own profiles. Only
those. Nothing else.

What belongs in sameAs

For a person: your Wikidata item, ORCID, GitHub, the LinkedIn profile that is
actually yours, your verified social accounts, your Crunchbase, your scholar
profiles. For an organization: its Wikidata item, its LinkedIn company page, its
Crunchbase org, its verified business listings. These are all the same entity,
elsewhere. That is the literal meaning of the property — "this is the same thing
as that."

What does NOT belong in sameAs

Backlink URLs you'd like to count. A page that links to you is not you.
Article URLs that mention you. A write-up about you is not a profile of you.
GitHub repository or pull-request URLs. A repo is a work product, not an identity.
A competitor's or a partner agency's URL. Obviously not you.
A sibling brand's marketing homepage as a raw link (use the sibling's schema @id and a real relationship like parentOrganization / subOrganization instead).

When you put non-identity URLs in sameAs, you're telling search engines and AI
models that those URLs are the entity. The reconciliation engine tries to merge
you with things that aren't you, your entity gets muddier, and the trust signal
you were trying to inflate deflates instead. I've seen exactly this produce a
measurable trust drop on a real site — the fix was deleting the junk entries, not
adding more.

How to model relationships correctly

The reason people abuse sameAs is usually that they're trying to express a
relationship — "this brand is part of that studio." sameAs is the wrong tool.
Use the relationship properties schema.org actually provides:

parentOrganization / subOrganization for a brand network.
worksFor / founder / employee for people-to-org.
memberOf, brand, publisher where they fit.

Anchor both ends with a stable @id (e.g. https://example.com/#org) and point
the relationship at that @id. Now the graph is reciprocal and machine-readable
without a single misused sameAs.

A quick audit you can run today

Open your JSON-LD, find every sameAs array, and ask of each URL: is this a
profile of the exact entity this node describes? If the answer is "no, but it's
related," move it to a relationship property. If the answer is "no, it's a
mention/backlink/repo," delete it.

I keep a set of canonical structured-data references — the full sameAs pattern, the
relationship properties, and worked org-network examples — at
ThatDevPro's reference library. The
patterns are boring on purpose. Boring is what survives an algorithm update.




---

I hand-build websites and full-stack engine optimization at [ThatDevPro](https://www.thatdevpro.com/) and [ThatDeveloperGuy](https://thatdeveloperguy.com/) — a service-disabled veteran-owned studio in Cassville, Missouri.

Person entity dual-founder pattern with spouse linkage for a husband-and-wife business

Joseph Anady — Tue, 26 May 2026 21:54:40 +0000

Person entity dual-founder pattern with spouse linkage for a husband-and-wife small business

Husband-and-wife co-founder businesses are common. The Schema.org graph for them rarely captures the relationship explicitly. Most sites declare both founders as separate Person entities with no link between them.

The denser pattern declares the spousal relationship inside the graph itself using the spouse property, then uses both ＠id references to make the entities reciprocally addressable.

This is the pattern I built for Steele Solutions, a husband-and-wife merchant services brokerage in Branson, Missouri.

The standard mistake

Two separate Person nodes, no relationship between them:

{
  "@graph": [
    {"@type": "Person", "@id": "https://example.com/#founder1", "name": "Jim Steele"},
    {"@type": "Person", "@id": "https://example.com/#founder2", "name": "Kim Steele"}
  ]
}

Google reads this as two independent people who happen to be at the same business. The spousal relationship is implied by name + same employer, but not declared.

The reciprocal-spouse pattern

{
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://steelesolutions4u.com/#jim",
      "name": "Jim Steele",
      "givenName": "Jim",
      "familyName": "Steele",
      "jobTitle": "Co-founder and Principal, CSSI National Account Executive",
      "spouse": {"@id": "https://steelesolutions4u.com/#kim"},
      "worksFor": {"@id": "https://steelesolutions4u.com/#organization"}
    },
    {
      "@type": "Person",
      "@id": "https://steelesolutions4u.com/#kim",
      "name": "Kim Steele",
      "givenName": "Kimberly",
      "additionalName": "Kayleen",
      "familyName": "Steele",
      "alternateName": ["Kim Steele", "Kimberly K. Steele", "Kimberly Kayleen Steele"],
      "jobTitle": "Co-founder and Principal, ATM Placement Program Lead",
      "spouse": {"@id": "https://steelesolutions4u.com/#jim"},
      "worksFor": {"@id": "https://steelesolutions4u.com/#organization"}
    }
  ]
}

Both Person entities reference each other through spouse. The graph is reciprocal. Google reads the relationship as a fact.

What the additionalName + alternateName pattern adds

The Schema.org Person type has three name-related properties:

name — the canonical display name
givenName — first name
familyName — last name
additionalName — middle name (or names)
alternateName — array of alternative names

For Kim Steele:

{
  "name": "Kim Steele",
  "givenName": "Kimberly",
  "additionalName": "Kayleen",
  "familyName": "Steele",
  "alternateName": [
    "Kim Steele",
    "Kimberly K. Steele",
    "Kimberly Kayleen Steele"
  ]
}

This captures every form the name takes across public records, social media, and informal contexts. Search engines reconciling "Kimberly K Steele Branson" with "Kim Steele Branson Solutions" hit a match through the alternateName array.

Cross-references to Organization

Both Person entities also reference the Org as worksFor:

"worksFor": {"@id": "https://steelesolutions4u.com/#organization"}

The Org entity reciprocally lists both as founder:

{
  "@type": ["LocalBusiness", "FinancialService", "ProfessionalService"],
  "@id": "https://steelesolutions4u.com/#organization",
  "name": "Steele Solutions",
  "founder": [
    {"@id": "https://steelesolutions4u.com/#jim"},
    {"@id": "https://steelesolutions4u.com/#kim"}
  ]
}

Now the graph forms a complete triangle: Jim ↔ Kim (via spouse), Jim → Org (via worksFor), Kim → Org (via worksFor), Org → Jim + Kim (via founder array).

Per-founder differentiation

Husband and wife at the same business often have different domains of expertise. The schema captures the differentiation through knowsAbout and hasCredential:

{
  "@id": "https://steelesolutions4u.com/#jim",
  "knowsAbout": [
    "Merchant Services",
    "POS Systems",
    "Credit Card Processing",
    "Cost Segregation",
    "Banking",
    "Small Business Lending"
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "CSSI National Account Executive",
      "credentialCategory": "Professional Designation"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "Indiana University Business Graduate",
      "credentialCategory": "Bachelor's Degree, Business"
    }
  ]
}

For Kim, a different knowsAbout:

{
  "@id": "https://steelesolutions4u.com/#kim",
  "knowsAbout": [
    "ATM Placement",
    "Merchant-Owned ATMs",
    "Free ATM Placement Program",
    "Operations",
    "Client Onboarding",
    "Merchant Services Account Management"
  ]
}

Both entities have full profile depth but with non-overlapping domains. The search engine can rank Jim for sales-side queries and Kim for operations-side queries.

What this signals

For a husband-and-wife co-founder business:

Explicit relationship: Google's Knowledge Graph treats the reciprocal spouse link as a verified fact rather than an inference
Disambiguation: when multiple Jim Steeles exist online, the spouse link to Kim Steele provides additional triangulation
AI engine clarity: ChatGPT and Claude treat the explicit relationship as a citation-worthy fact when describing the business
Knowledge Panel reconciliation: Google may eventually build a Knowledge Panel for the business that names both founders correctly

For Steele Solutions, the complete dual-founder graph is at https://steelesolutions4u.com/entity.json.

References

Schema.org spouse property
Schema.org Person type
Schema.org alternateName property
Public Steele Solutions resources at github.com/Janady13/steele-solutions-resources

The four AI citation surfaces every small business website should publish in 2026

Joseph Anady — Tue, 26 May 2026 21:53:34 +0000

llms.txt, aeo.json, entity.json, brand.json: the four AI citation surfaces for a small business

In 2026, search engines and AI engines see your site differently. Google indexes HTML. ChatGPT crawls for citations. Claude probes for entity facts. Perplexity wants structured answers.

Each of these engines reads different files. The four canonical AI citation surfaces are:

/llms.txt — natural-language identity for LLM crawlers
/aeo.json — Answer-Engine Optimization structured manifest
/entity.json — Schema.org ＠graph as a standalone file
/brand.json — Brand identity, voice, and design system

Most small business sites have zero of these. The ones that do typically have one. For Steele Solutions, a merchant services brokerage in Branson Missouri, all four surfaces are deployed and crawler-visible.

Here is what each file does and why.

/llms.txt

The proposed llms.txt standard is a natural-language identity declaration for LLM crawlers. The format:

# Steele Solutions

> Family-run merchant services brokerage based in Branson, Missouri. Founded by Jim and Kim Steele. Serves the Ozarks region with five integrated service lines under the Business CPR framework: POS systems, credit card processing, ATM placements, business lending, and CSSI cost segregation studies.

## Services

- POS Systems: https://steelesolutions4u.com/pos-systems/
- Credit Card Processing: https://steelesolutions4u.com/credit-card-processing/
- ATM Placements: https://steelesolutions4u.com/atm-placements/
- Business Lending: https://steelesolutions4u.com/business-lending/
- CSSI Cost Segregation: https://steelesolutions4u.com/cssi-cost-segregation/

## Find us on Google

Google Maps: https://www.google.com/maps?cid=07508619094055456934
Google Maps CID: 07508619094055456934

Markdown format. Headers map to concept clusters. Bullet lists map to facts. LLMs are trained on documents that follow this structure, so they parse it cleanly.

The llms.txt is currently honored by Anthropic's Claude and is widely scraped by other LLM training pipelines.

/aeo.json

AEO (Answer Engine Optimization) is the proposed JSON equivalent of llms.txt for structured answer-engine ingestion. Format:

{
  "schema_version": "2.0",
  "site": "steelesolutions4u.com",
  "name": "Steele Solutions",
  "title": "Steele Solutions — Branson MO Merchant Services & Cost Segregation",
  "description": "...",
  "vertical": "merchant-services",
  "primary_topic": "Independent merchant-services brokerage",
  "founded": "2024",
  "founders": [
    {"name": "Jim Steele", "role": "Co-founder, CSSI National Account Executive"},
    {"name": "Kim Steele", "role": "Co-founder, ATM Placement Program Lead"}
  ],
  "address": {"locality": "Branson", "region": "MO", "country": "US"},
  "service_area": ["Missouri", "Arkansas", "Oklahoma", "Kansas"],
  "services": ["POS Systems", "Credit Card Processing", ...],
  "google": {
    "maps_cid": "07508619094055456934",
    "maps_url": "https://www.google.com/maps?cid=07508619094055456934"
  },
  "sameAs": [
    "https://www.google.com/maps?cid=07508619094055456934",
    "https://cssiservices.com/sales/jim-steele/",
    "https://web.archive.org/web/2026/https://steelesolutions4u.com/"
  ]
}

JSON-structured, machine-parseable, includes the same facts as llms.txt but in a format that programmatic ingestion pipelines prefer.

/entity.json

The Schema.org ＠graph as a standalone, addressable JSON-LD file:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": ["LocalBusiness", "FinancialService", "ProfessionalService"],
      "@id": "https://steelesolutions4u.com/#organization",
      "name": "Steele Solutions",
      "sameAs": [...],
      "hasOfferCatalog": {...},
      "areaServed": [...],
      ...
    },
    {"@type": "Person", "@id": "https://steelesolutions4u.com/#jim", ...},
    {"@type": "Person", "@id": "https://steelesolutions4u.com/#kim", ...},
    {"@type": "WebSite", "@id": "https://steelesolutions4u.com/#website", ...}
  ]
}

The same schema is also embedded inline on every HTML page. The standalone /entity.json file gives crawlers (and AI engines) a single URL that returns the complete entity graph without HTML noise.

/brand.json

Brand identity, voice, and design system as a machine-readable manifest:

{
  "name": "Steele Solutions",
  "alternateNames": ["Steele Solutions Branson", "SteeleSolutions"],
  "tagline": "Honest merchant services from the Ozarks",
  "founded": "2024",
  "headquarters": "Branson, MO",
  "telephones": ["+14172941882", "+14172311349"],
  "email": "steelesolutions4u@gmail.com",
  "website": "https://steelesolutions4u.com/",
  "colors": {"primary": "#1a3a52", "accent": "#3a8b9f"},
  "fonts": {"display": "Fraunces", "body": "Inter"},
  "voice": "Direct, professional, no upsell pressure. The 'free statement audit' anchors the trust signal.",
  "services": [...],
  "google": {"maps_cid": "07508619094055456934"},
  "listings": {
    "googleBusinessProfile": {
      "cid": "07508619094055456934",
      "url": "https://www.google.com/maps?cid=07508619094055456934",
      "verified": false
    }
  },
  "sameAs": [...]
}

The brand.json is consumed by design-system tooling and by AI agents that need to reproduce the brand's voice when generating content about the business.

Putting them together

A standard <head> block on every page references all four files:

<link rel="alternate" type="text/plain" href="/llms.txt" title="LLM identity">
<link rel="alternate" type="application/json" href="/aeo.json" title="AEO">
<link rel="alternate" type="application/ld+json" href="/entity.json" title="Entity graph">
<link rel="alternate" type="application/json" href="/brand.json" title="Brand">

These are crawler discovery hints. AI engine bots that read alternate link headers find the files and ingest them as structured supplements to the HTML content.

Where each file goes

For nginx:

location = /llms.txt {
  root /var/www/sites/steelesolutions;
  default_type text/plain;
}
location = /entity.json {
  root /var/www/sites/steelesolutions;
  default_type application/ld+json;
}
location = /aeo.json {
  root /var/www/sites/steelesolutions;
  default_type application/json;
}
location = /brand.json {
  root /var/www/sites/steelesolutions;
  default_type application/json;
}

The default_type ensures the MIME type is correct. AI engine crawlers check Content-Type before parsing.

What this signals

For a brand-new small business site, the four-surface stack signals:

The site is engineered with AI-engine discovery as a deliberate goal
The business identity has been formally declared, not just implied through page content
There is structured authority data available without HTML noise
The site participates in the emerging AI citation ecosystem

For Steele Solutions, all four files are live at the site root:

References

llms.txt proposed standard
Schema.org JSON-LD
Public Steele Solutions resources at github.com/Janady13/steele-solutions-resources

Wikidata Q-ID chaining: anchoring a business credential to a verifiable institution

Joseph Anady — Tue, 26 May 2026 21:52:48 +0000

Wikidata Q-ID chaining: how to anchor a business credential to a verifiable institution

Schema.org's hasCredential field accepts a flat string for the credential name. Most sites use it that way:

"hasCredential": "President's Club"

This is technically valid. It is also useless for entity reconciliation. The string "President's Club" could be Toastmasters, an airline frequent flyer tier, or any of a thousand sales-recognition programs across every industry. Google has no way to disambiguate.

The denser pattern uses EducationalOccupationalCredential with recognizedBy chained to an Organization that includes a Wikidata Q-ID:

"hasCredential": [{
  "@type": "EducationalOccupationalCredential",
  "name": "First National Bank of Omaha President's Club",
  "credentialCategory": "Sales Performance Award",
  "recognizedBy": {
    "@type": "BankOrCreditUnion",
    "name": "First National Bank of Omaha",
    "url": "https://www.fnbo.com/",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q5453412",
      "https://en.wikipedia.org/wiki/First_National_Bank_of_Omaha"
    ],
    "identifier": [
      {"@type": "PropertyValue", "propertyID": "WikidataQID", "value": "Q5453412"}
    ]
  }
}]

Now Google's Knowledge Graph can traverse the chain:

Read the credential name
Identify the issuing institution
Reconcile the institution to its Wikidata entity (Q5453412)
Verify the institution exists in the Knowledge Graph
Assign credibility to the credential because it is issued by a verified entity

This is what I built into Steele Solutions for Jim Steele's career history. Three credentials, three Wikidata-anchored institutions.

The pattern

For any credential where the issuing institution is in Wikipedia or Wikidata, the chained pattern works:

"hasCredential": [
  {
    "@type": "EducationalOccupationalCredential",
    "name": "{degree or award name}",
    "credentialCategory": "{Bachelor's Degree | Sales Performance Award | Certification | Professional Designation}",
    "recognizedBy": {
      "@type": "{CollegeOrUniversity | BankOrCreditUnion | Organization | ProfessionalAssociation}",
      "name": "{institution name}",
      "url": "{institution URL}",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q{QID}",
        "https://en.wikipedia.org/wiki/{slug}"
      ],
      "identifier": [
        {"@type": "PropertyValue", "propertyID": "WikidataQID", "value": "Q{QID}"}
      ]
    }
  }
]

The identifier array with WikidataQID is the explicit identifier-typed declaration. Google reads either the sameAs URL or the identifier value and resolves to the same entity. Including both gives crawlers redundancy.

Finding the Q-ID

For any major institution, the Wikidata Q-ID is on the right sidebar of the Wikipedia page. Or search Wikidata's entity search for the institution name.

Examples relevant to Steele Solutions' graph:

Institution	Wikidata Q-ID	Wikipedia URL
Indiana University Bloomington	Q1079140	en.wikipedia.org/wiki/Indiana_University_Bloomington
First National Bank of Omaha	Q5453412	en.wikipedia.org/wiki/First_National_Bank_of_Omaha
Indiana University Kelley School of Business	Q6123576	en.wikipedia.org/wiki/Kelley_School_of_Business
Schema.org	Q1521	en.wikipedia.org/wiki/Schema.org

For a credential, the load-bearing field is recognizedBy.identifier[].value containing the Q-ID. The sameAs URLs are reinforcement.

Beyond credentials: alumniOf, memberOf, knowsAbout

The same Q-ID chaining applies to other Person fields:

"alumniOf": [{
  "@type": "CollegeOrUniversity",
  "name": "Indiana University Bloomington",
  "url": "https://www.indiana.edu/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q1079140",
    "https://en.wikipedia.org/wiki/Indiana_University_Bloomington"
  ]
}],

"memberOf": [{
  "@type": "Organization",
  "name": "CSSI Cost Segregation Services, Inc.",
  "url": "https://cssiservices.com/",
  "description": "America's leading engineering-based cost segregation firm. 60,000+ studies completed; $55B+ in client tax savings."
}]

alumniOf for educational institutions. memberOf for professional bodies, alumni associations, trade groups. knowsAbout typically takes plain strings, but can also take URLs pointing to Wikipedia articles for each topic:

"knowsAbout": [
  "Merchant Services",
  "Cost Segregation",
  "https://en.wikipedia.org/wiki/Cost_segregation"
]

The Wikipedia URL form is rarer but is parsed correctly by Google. It maps the topic name to its Wikipedia entity for tighter reconciliation.

What this buys you

For an individual with a long career, the chained-Q-ID pattern produces:

Knowledge Graph entries: Google may eventually generate a Knowledge Graph card for the person, anchored by the institutional chain
AI engine recognition: ChatGPT, Claude, and Perplexity treat Wikidata Q-IDs as verifiable third-party assertions
Faster trust accumulation: a new domain hosting a Person entity with three Q-ID-chained credentials accumulates trust faster than one with flat-string credentials
Disambiguation: a common name (like "Jim Steele") becomes disambiguated through the unique combination of institutional Q-IDs

For Jim Steele on Steele Solutions, the three Q-ID-chained credentials (CSSI National Account Executive, Indiana University Business graduate, First National Bank of Omaha President's Club) form a triangulation that identifies him uniquely.

Verification

The Schema.org Markup Validator at validator.schema.org parses the chained pattern without errors. Google's Rich Results Test recognizes the structure.

For a real-world implementation, see https://steelesolutions4u.com/entity.json. The Jim and Kim Steele entities use Wikidata Q-IDs throughout.

References

Wikidata Q-ID search
Schema.org EducationalOccupationalCredential
Schema.org recognizedBy
Public resources at github.com/Janady13/steele-solutions-resources

GoodRelations payment method URIs: the underused Schema.org pattern for financial services

Joseph Anady — Tue, 26 May 2026 21:52:01 +0000

GoodRelations payment method URIs: the underused Schema.org pattern for financial services

Schema.org has a built-in paymentAccepted string property, and a paymentMethod URL-typed property. Most sites use the first, skip the second, and lose half the entity-graph signal.

The paymentMethod field accepts URIs from the GoodRelations vocabulary, which provides explicit machine-readable identifiers for every common payment instrument. For a financial services or merchant services business, the GoodRelations URIs feed directly into Google's Knowledge Graph and into AI engines (ChatGPT, Claude, Gemini, Perplexity) as structured facts.

This is the pattern as it appears on Steele Solutions, a Branson MO merchant services brokerage.

The standard mistake

Most sites declare payment methods like this:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "paymentAccepted": "Cash, Check, Credit Card"
}

A flat human-readable string. Google reads it. The Knowledge Graph parses some recognizable terms. The signal is shallow.

The GoodRelations pattern

{
  "@context": "https://schema.org",
  "@type": ["LocalBusiness", "FinancialService"],
  "paymentAccepted": "Cash, Check, ACH, Wire, Visa, Mastercard, American Express, Discover",
  "paymentMethod": [
    "http://purl.org/goodrelations/v1#Cash",
    "http://purl.org/goodrelations/v1#Check",
    "http://purl.org/goodrelations/v1#PaymentMethodCreditCard",
    "http://purl.org/goodrelations/v1#DirectDebit",
    "http://purl.org/goodrelations/v1#ByBankTransferInAdvance"
  ]
}

The URI array is the explicit, deterministic version. Each URI is a machine-readable identifier that maps to a single payment-method concept. Google does not have to do natural-language parsing.

Available GoodRelations payment-method URIs

The full list of GoodRelations payment-method URIs (most often used):

URI	Maps to
`http://purl.org/goodrelations/v1#Cash`	Physical cash transactions
`http://purl.org/goodrelations/v1#Check`	Paper or electronic check
`http://purl.org/goodrelations/v1#PaymentMethodCreditCard`	Generic credit card
`http://purl.org/goodrelations/v1#DirectDebit`	Bank account ACH
`http://purl.org/goodrelations/v1#ByBankTransferInAdvance`	Wire transfer
`http://purl.org/goodrelations/v1#ByInvoice`	Net-30 invoice billing
`http://purl.org/goodrelations/v1#COD`	Cash on delivery
`http://purl.org/goodrelations/v1#GoogleCheckout`	(historical)
`http://purl.org/goodrelations/v1#PayPal`	(deprecated, use string)
`http://purl.org/goodrelations/v1#PaymentMethodCard`	Generic card payment

For specific card brands (Visa, Mastercard, etc.), the GoodRelations vocabulary defines:

URI	Brand
`http://purl.org/goodrelations/v1#VISA`	Visa
`http://purl.org/goodrelations/v1#MasterCard`	Mastercard
`http://purl.org/goodrelations/v1#AmericanExpress`	American Express
`http://purl.org/goodrelations/v1#Discover`	Discover
`http://purl.org/goodrelations/v1#JCB`	JCB
`http://purl.org/goodrelations/v1#DinersClub`	Diners Club

These are the canonical identifiers for each card network as far as the linked-data web is concerned.

What this signals

For a merchant services brokerage, the GoodRelations array signals:

Topical relevance: a business that explicitly enumerates GoodRelations URIs is participating in the structured-payments-vocabulary ecosystem. Google's Knowledge Graph treats this as a strong indicator that the business is in payment processing, not in retail or restaurants.
Crawler clarity: AI engines parsing the page get unambiguous payment-method facts.
Validation pass: Google's Rich Results Test recognizes GoodRelations URIs as valid paymentMethod values.
Future-proofing: Schema.org may add native enums for payment methods someday. GoodRelations is the bridge until then.

What this does not signal

GoodRelations URIs do not currently produce rich snippets, knowledge panels, or special SERP features by themselves. The benefit is upstream — it strengthens the entity graph for Knowledge Graph reconciliation and AI-engine indexing.

The Steele Solutions example

For Steele Solutions, the paymentMethod array works alongside the broader Schema.org graph:

{
  "@type": ["LocalBusiness", "FinancialService", "ProfessionalService"],
  "@id": "https://steelesolutions4u.com/#org",
  "currenciesAccepted": "USD",
  "paymentAccepted": "Cash, Check, ACH, Wire, Visa, Mastercard, American Express, Discover",
  "paymentMethod": [
    "http://purl.org/goodrelations/v1#Cash",
    "http://purl.org/goodrelations/v1#Check",
    "http://purl.org/goodrelations/v1#PaymentMethodCreditCard",
    "http://purl.org/goodrelations/v1#DirectDebit",
    "http://purl.org/goodrelations/v1#ByBankTransferInAdvance"
  ],
  "priceRange": "$0 install, no contracts. Statement audit free."
}

Combined with the FinancialService type and the 10-service hasOfferCatalog, the GoodRelations URIs round out the merchant-services entity declaration.

How to verify

Test the markup at Google's Rich Results Test. The paymentMethod field with GoodRelations URIs should validate without warnings. The Knowledge Graph reconciliation pass happens in the background after Google indexes the page.

For Steele Solutions, the complete schema is at https://steelesolutions4u.com/entity.json. The site implementation is at https://steelesolutions4u.com/.

Reference

Country-spanning service-area schema: 17 cities and places in one Organization graph

Joseph Anady — Tue, 26 May 2026 21:41:20 +0000

Country-spanning service-area schema: 17 cities and places in one Organization graph

A merchant services brokerage in the Ozarks region serves a four-state corridor: Missouri, Arkansas, Oklahoma, and Kansas. The site needs to rank for "credit card processing Branson MO" and "ATM placement Eureka Springs AR" with the same authority signal.

Schema.org gives you areaServed for exactly this. Most implementations stop at one city. Here is how Steele Solutions declares 17 distinct areas in a single Organization graph node, blending City, State, and Place types with containedInPlace chaining.

The flat-string mistake

The temptation is to write:

"areaServed": "Branson, Missouri and surrounding areas"

This is technically valid Schema.org. Google reads the string and infers a service area. But the inference is shallow. Google does not know which cities are in the area. The Knowledge Graph does not reconcile the cities to their Wikidata entries.

The dense pattern uses an array of typed objects:

"areaServed": [
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Springfield", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  ...
]

Each city is an explicit entity. The containedInPlace chain tells Google that Branson is in Missouri. The State entity gets its own Knowledge Graph reconciliation.

City vs Place

Some service areas are not political units. Lake Taneycomo is a body of water. Branson Landing is a commercial district. These cannot be City. Use Place:

[
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "Place", "name": "Lake Taneycomo"},
  {"@type": "Place", "name": "Table Rock Lake"},
  {"@type": "Place", "name": "Branson Landing"},
  {"@type": "Place", "name": "the Ozarks"}
]

Mixing City and Place is fine. Both inherit from Place in the Schema.org type hierarchy. Google handles the mixed array correctly.

The full Steele Solutions areaServed

The complete areaServed for Steele Solutions, spanning Missouri and Arkansas with associated lake and regional entities:

"areaServed": [
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Hollister", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Forsyth", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Kimberling City", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Cassville", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Springfield", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Joplin", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Reeds Spring", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Lake of the Ozarks", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Bentonville", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Rogers", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Eureka Springs", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Berryville", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "Place", "name": "Lake Taneycomo"},
  {"@type": "Place", "name": "Table Rock Lake"},
  {"@type": "Place", "name": "Branson Landing"},
  {"@type": "Place", "name": "the Ozarks"}
]

13 cities, 4 places, 17 total areas in one declaration.

Why containedInPlace matters

Without containedInPlace, the City entity is ambiguous. Branson exists in Missouri but also in Colorado. Springfield exists in 35+ US states. The chained containedInPlace resolves the ambiguity for Google's Knowledge Graph.

The chain can go deeper. For a sub-state region:

{
  "@type": "City",
  "name": "Branson",
  "containedInPlace": {
    "@type": "AdministrativeArea",
    "name": "Taney County",
    "containedInPlace": {"@type": "State", "name": "Missouri"}
  }
}

This tells Google: Branson is in Taney County, which is in Missouri. For a service business where county boundaries matter, the deeper chain is worth the verbosity.

Per-area landing pages

The areaServed declaration is the entity-graph statement. The site also needs landing pages for each area. Steele Solutions has:

/branson-mo/
/locations/springfield-mo/
/locations/joplin-mo/
/locations/hollister-mo/
/locations/forsyth-mo/
/locations/kimberling-city-mo/
/locations/reeds-spring-mo/
/locations/lake-of-the-ozarks/
/locations/bentonville-ar/
/locations/rogers-ar/
/locations/eureka-springs-ar/
/locations/berryville-ar/
/ozarks-region/ (regional hub)
/locations/ (location index)

Each page has its own page-level schema with the City as the WebPage about. Cross-link from the homepage areaServed to each landing page where possible.

What ranking changes to expect

For a brand-new domain, dense areaServed declaration produces:

Faster discovery of per-area landing pages
More query-specific impressions in GSC (e.g., separate impressions for "credit card processing Bentonville AR" vs "credit card processing Branson MO")
Cleaner Knowledge Panel reconciliation
AI Overview citations for region-specific queries

For Steele Solutions on day 7 of launch, GSC was already showing impressions for at least 3 different region+service combinations.

The live example

The complete entity graph including the 17-area areaServed declaration is at https://steelesolutions4u.com/entity.json. The same schema is embedded inline on every page of the site.

Live site: https://steelesolutions4u.com/. Service-area pages start at https://steelesolutions4u.com/locations/.

Tools used

Schema.org Place hierarchy reference
Schema.org areaServed reference
Google Rich Results Test
Public resources at github.com/Janady13/steele-solutions-resources

Indexing rescue for a 7-day-old domain: 4 of 18 priority pages indexed in 6 days

Joseph Anady — Tue, 26 May 2026 21:40:35 +0000

Indexing rescue for a 7-day-old domain: how we got 4 of 18 priority pages indexed in 6 days

A brand-new domain is in a special category for Google. The crawler discovers URLs from the sitemap, queues them for indexing, then often holds them in "Discovered, currently not indexed" status for weeks or months. The site is real. The content is fine. Google just hasn't decided to allocate the index slots yet.

This is the standard new-domain experience. For Steele Solutions, launched 2026-05-19 — a family-run merchant services brokerage in Branson, Missouri — we hit the same wall on day 2.

Here is the indexing rescue stack that took us from 0 indexed pages to 4 of 18 priority pages indexed within 6 days.

The starting state

GSC URL Inspection on day 2:

Page	Coverage
/ (homepage)	Submitted and indexed
/credit-card-processing/	Discovered - currently not indexed
/pos-systems/	Discovered - currently not indexed
/atm-placements/	Discovered - currently not indexed
/business-lending/	Discovered - currently not indexed
/cssi-cost-segregation/	Discovered - currently not indexed
/dual-pricing/	Discovered - currently not indexed
...12 more	Discovered - currently not indexed

1 of 18 indexed. Standard for a 7-day-old domain.

The rescue stack

IndexNow to Bing and Yandex

IndexNow is a search-engine-side push API. You POST a list of URLs plus a verification key, and Bing and Yandex acknowledge with HTTP 200 within seconds.

The IndexNow signal does propagate to Google indirectly. Google's Discovery layer reads multiple signals from across the search ecosystem when deciding which URLs to crawl. A URL submitted via IndexNow is more likely to get an early crawl from Googlebot than a URL that only appears in your sitemap.

curl -X POST 'https://yandex.com/indexnow' \
  -H 'Content-Type: application/json' \
  -d '{"host":"steelesolutions4u.com",
       "key":"YOUR_KEY",
       "keyLocation":"https://steelesolutions4u.com/YOUR_KEY.txt",
       "urlList":[
         "https://steelesolutions4u.com/",
         "https://steelesolutions4u.com/credit-card-processing/"
       ]}'

For Steele, we submitted all 26 priority URLs to Yandex within 24 hours of launch. Each submission got an HTTP 202 acknowledgment.

Wayback Machine archive of every URL

The Internet Archive's Wayback Machine becomes a discovery signal for Google because Common Crawl licenses Wayback data for URL discovery. When you submit a URL to https://web.archive.org/save/YOUR_URL, the archive crawler immediately fetches and stores the page. The archive URL is permanently accessible and indexable.

For Steele, we ran a Python script that submitted all 43 sitemap URLs to Wayback, paced at 5 seconds between submissions to avoid rate limiting:

import urllib.request, time
for url in priority_urls:
    save_url = f"https://web.archive.org/save/{url}"
    urllib.request.urlopen(save_url, timeout=30)
    time.sleep(5)

Result: 43 of 43 URLs archived. The Wayback Machine snapshots for Steele Solutions are at https://web.archive.org/web/2026/https://steelesolutions4u.com/.

GSC URL Inspection API

The Google Search Console URL Inspection API lets you inspect any URL on your verified property. Calling urlInspection().index().inspect() returns the URL's coverage state, last crawl time, and indexing verdict.

The act of inspecting a URL signals discovery interest to Google. Google does not document this as a feature, but the empirical observation is: URLs that are inspected via the API show faster movement from "Discovered" to "Submitted and indexed" than URLs that are not.

For Steele, we ran the inspection API across all 18 priority URLs on day 3. The inspection results helped us identify URLs that were stuck and URLs that were progressing.

Cross-site link equity

A fresh domain has no external referring domains. Internal link equity flows only within the site. Cross-linking from existing high-DA properties accelerates discovery.

For Steele Solutions, we added inbound links from:

A studio portfolio: https://www.thatdevpro.com/portfolio/case-studies/steele-solutions/
The parent agency case studies index
The hosting network's "Sites already on the network" grid
A GitHub profile README's "Recent client work" section (DA 96 referring domain)
A canonical Person hub at https://feedthejoe.com/joseph/ "Recent client work"

Each link transfers some link equity. The Discover queue moves faster when external referrers exist.

Schema.org density

A dense entity graph signals legitimacy. Steele Solutions has:

LocalBusiness + FinancialService + ProfessionalService combined types
hasOfferCatalog with 10 services, each with a URL
17 areaServed entities
Two Person founders with full bios, hasCredential with recognizedBy organization URIs, alumniOf with Wikidata Q-IDs
15+ sameAs URLs spanning Wayback archive, Taney County public records, partner sites, and Google Maps CID

Google's structured data testing tool rates the schema. AI engines weigh it. Dense schema correlates with faster index inclusion.

Public verification page

The verification page aggregates every claim on the site with a third-party source link. Sections cover business identity, principal career history, partner network, where we appear publicly, and Taney County, Missouri public records.

When Google crawls /verification/, it finds outbound citations to Wikipedia (Q1079140, Q5453412), Wikidata, the Internet Archive Wayback Machine, the CSSI directory, and the Taney County Collector. The page becomes a topical hub that demonstrates third-party verification.

The results timeline

Day	Pages indexed	New action
1	0	Site launched
2	1 (homepage)	Sitemap submitted
3	1	IndexNow + Wayback + GSC URL Inspection
5	3 (homepage, /about/, /branson-mo/)	Schema enrichment wave
6	4 (added /cssi-cost-segregation/)	Verification page published
7	4 + 12 in "Discovered" queue	Continuing IndexNow submissions

By day 7, 4 of 18 priority pages were indexed. The remaining 12 were in the Discovery queue, all submitted to Google's indexing pipeline and waiting their turn.

For a 7-day-old domain, that pace is significantly faster than the typical 30-90 day baseline.

The takeaways

For a new-domain indexing rescue:

Submit to IndexNow within 24 hours of every URL change
Archive every URL to Wayback Machine on day 1
Call GSC URL Inspection API on priority URLs
Build inbound links from at least 3 high-DA properties you control
Dense Schema.org markup with sameAs, Wikidata Q-IDs, and partner references
A /verification/ page aggregating all third-party citations in one place

The site for the example is at https://steelesolutions4u.com/. Live verification page at https://steelesolutions4u.com/verification/. Public resources at github.com/Janady13/steele-solutions-resources.

Building an indexable verification page for a freshly-launched small business

Joseph Anady — Tue, 26 May 2026 21:38:34 +0000

Building an indexable verification page for a freshly-launched small business site

When a small business launches a new website, Google treats it as untrusted for 30 to 90 days. New domain. No backlinks. No reviews. No knowledge panel. The site might be technically perfect, but Google won't promote it until external trust signals appear.

The standard advice is: build backlinks, get reviews, sign up for directories, hope for press coverage. All slow. Some take months.

There's a faster move: build a /verification/ page on the site itself that aggregates every verifiable third-party citation in one place. Make the website itself the authority.

I built this for Steele Solutions, a family-run merchant services brokerage in Branson, Missouri, in May 2026. Here's the pattern.

The page structure

The verification page is a series of tables. Each row is one claim and one third-party source URL where anyone can verify it. The format:

Claim	Source description	Verify URL
Headquarters Branson, MO	Address on every site page	`/contact/`
Domain registered 2026-05-19	ICANN WHOIS	lookup.icann.org
Google Business Profile CID 07508619094055456934	Google Maps	google.com/maps?cid=...
Wayback Machine archive	Internet Archive snapshot	web.archive.org

Every claim links out. Anyone reading the page can click each link and confirm the claim independently. Google can crawl each outbound link and follow the citation chain to the same conclusion.

Section 1: business identity

The first table covers the basics — name, address, phone, domain age, Google Business Profile CID, Wayback Machine snapshot. Each entry is verifiable through a single click.

The Wayback URL is critical. It is the most permanent citation on the internet. When the Wayback Machine captures your site, that snapshot becomes a public-record timestamp of every claim on your homepage. Future crawlers can traverse to the archive and confirm exactly what your site said on the day it was archived.

For Steele Solutions, the homepage was archived on 2026-05-26 at https://web.archive.org/web/20260526012306/https://steelesolutions4u.com/. Anyone can verify that all the claims on the live site were also on the site at archive time.

Section 2: principal career history

For Steele Solutions, both founders are listed with verifiable career claims:

Jim Steele: CSSI National Account Executive — links to https://cssiservices.com/sales/jim-steele/ (live) plus https://web.archive.org/web/20251209135730/https://cssiservices.com/sales/jim-steele/ (Wayback-archived snapshot from 2025-12-09).
Indiana University Bloomington Business graduate — links to https://www.wikidata.org/wiki/Q1079140 plus https://en.wikipedia.org/wiki/Indiana_University_Bloomington.
First National Bank of Omaha President's Club — links to https://www.wikidata.org/wiki/Q5453412 plus https://en.wikipedia.org/wiki/First_National_Bank_of_Omaha.

The Wikidata Q-IDs reconcile the claims with the Google Knowledge Graph. Google reads the Q-ID and understands the institution. The Wikipedia URL reinforces it. The Wayback Machine snapshot of the CSSI profile gives Google a permanent third-party citation that doesn't depend on the live CSSI page staying up.

Section 3: partner network with FTC disclosure

Steele Solutions is a brokerage. It earns commissions from referrals. FTC rules require affiliate disclosure. The verification page includes:

A 10-row table listing every processor, lender, and cost segregation partner
Each row links to the partner's live site
Below the table, an explicit statement that Steele may receive commission on referrals

This serves two purposes. First, regulatory compliance. Second, the table is a list of 10 outbound links to high-DA financial-services sites (electronicpayments.com, shift4.com, squareup.com, cssiservices.com, etc.). Google interprets that as topical relevance signal — Steele Solutions is in the merchant-services ecosystem because they cite merchant-services partners.

Section 4: where we appear publicly

Plain English list of every place the business is publicly recorded:

Wayback Machine: 43 of 43 URLs archived
Google Search Console: domain verified, sitemap submitted, IndexNow accepted
Bing and Yandex: IndexNow submitted via API
AI engine surfaces: llms.txt, aeo.json, entity.json, brand.json
Cross-citations: TDP portfolio, TDG case studies, TWHG network grid

Each item links to the verification URL where you can confirm independently.

Section 5: public records (the load-bearing one)

For Steele Solutions, the verification page references Taney County, Missouri public real estate ownership records — without publishing the home address. The phrasing:

"Kimberly and James Steele are jointly listed in Taney County, Missouri public real estate ownership records and personal property tax filings as residents of Branson, Missouri (ZIP 65616). For privacy reasons we do not publish their home address, but anyone can independently verify ownership at the Taney County Collector's search tool."

Then a table links to:

https://www.taneycountycollector.com/realsearch.php (search owner: STEELE)
https://www.taneycountycollector.com/personalsearch.php
https://beacon.schneidercorp.com/?site=TaneyCountyMO (parcel viewer)
https://taneycountyassessor.net/ (Taney County Assessor)

Anyone doing due diligence can independently confirm the owners exist in county public records without the site exposing their home address. This is the maximum-verification minimum-disclosure pattern.

Why this works

Google's algorithm prioritizes E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). For a brand-new domain with no inbound links, the standard verification path is slow. The /verification/ page short-circuits the wait by giving Google everything it needs to verify the business in one crawl.

In Steele Solutions' case, within 14 days of launch:

Homepage indexed and ranking position 2 average for branded queries
Verification page indexed
6 of 26 priority pages moved from "Discovered, not indexed" to "Submitted and indexed"
First click-through from organic search

The /verification/ page works because it converts dispersed third-party citations into a single dense surface that Google can crawl and reconcile in one pass.

Template

The pattern is repeatable. For your own small business site:

Identify every verifiable claim on the site
Find a third-party source for each claim
Build a table with three columns: Claim, Source description, Verify URL
Group tables into sections: identity, principals, partners, public records, where we appear
Link out aggressively to every cited source
Submit the page to IndexNow + Wayback Machine the day it ships
Cross-link from your homepage navigation so internal link equity flows to it

The full live Steele Solutions verification page is at https://steelesolutions4u.com/verification/.

Tools used

Schema.org for the entity graph
Wikidata for institutional Q-IDs
Internet Archive Wayback Machine for permanent citation URLs
Google Search Console URL Inspection API for discovery
IndexNow for accelerated submission to Bing and Yandex
Taney County Collector for the property ownership verification

Public repository at github.com/Janady13/steele-solutions-resources.

FinancialService schema for a real merchant services brokerage: a case study

Joseph Anady — Tue, 26 May 2026 21:37:21 +0000

FinancialService schema for a real merchant services brokerage: a case study

Schema.org gives you FinancialService as a type. Most sites that use it stop there. Combined with LocalBusiness, ProfessionalService, and a properly populated hasOfferCatalog, it becomes one of the highest-density entity declarations you can put on a small business site.

This is a walkthrough of how I structured the entity graph for Steele Solutions, a family-run merchant services brokerage in Branson, Missouri.

The starting type chain

{
  "＠context": "https://schema.org",
  "＠graph": [{
    "＠type": ["LocalBusiness", "FinancialService", "ProfessionalService"],
    "＠id": "https://steelesolutions4u.com/#org",
    "name": "Steele Solutions",
    "url": "https://steelesolutions4u.com/",
    "description": "Branson Missouri merchant services firm..."
  }]
}

The triple ＠type is intentional. LocalBusiness gets you into Google's local pack discovery. FinancialService is the topical type that signals "this is a financial-services business, not a retailer." ProfessionalService reinforces it for the Knowledge Graph reconciliation pass.

hasOfferCatalog: the service spine

hasOfferCatalog is where most small business schemas fall over. The spec asks for an OfferCatalog with itemListElement containing Offer objects, each wrapping a Service. Most sites either skip it, or list a single Offer with no URL.

For Steele, every service maps to a real URL on the site:

"hasOfferCatalog": {
  "＠type": "OfferCatalog",
  "name": "Steele Solutions Service Catalog",
  "itemListElement": [
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "POS Systems", "url": "https://steelesolutions4u.com/pos-systems/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Credit Card Processing", "url": "https://steelesolutions4u.com/credit-card-processing/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "ATM Placements", "url": "https://steelesolutions4u.com/atm-placements/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Small Business Lending", "url": "https://steelesolutions4u.com/business-lending/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "CSSI Cost Segregation Studies", "url": "https://steelesolutions4u.com/cssi-cost-segregation/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Dual Pricing and Cash Discount Programs", "url": "https://steelesolutions4u.com/dual-pricing/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Free POS Placement", "url": "https://steelesolutions4u.com/free-pos/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Square Account Setup via Authorized Referral", "url": "https://steelesolutions4u.com/apply/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Business CPR Framework", "url": "https://steelesolutions4u.com/business-cpr/"}},
    {"＠type": "Offer", "itemOffered": {"＠type": "Service", "name": "Cryptocurrency Payment Acceptance via Shift4", "url": "https://steelesolutions4u.com/services/"}}
  ]
}

Ten services. Every Service item has both a name and a URL. The URL bridges the entity graph to the actual page where that service is sold. Google AI Overview and Perplexity both treat the URL on itemOffered as the authoritative source for that service offering.

areaServed: explicit geography

Most merchant services sites declare their city and stop. But a brokerage like Steele's serves multiple states. The schema reflects that exactly:

"areaServed": [
  {"＠type": "City", "name": "Branson", "containedInPlace": {"＠type": "State", "name": "Missouri"}},
  {"＠type": "City", "name": "Springfield", "containedInPlace": {"＠type": "State", "name": "Missouri"}},
  {"＠type": "City", "name": "Joplin", "containedInPlace": {"＠type": "State", "name": "Missouri"}},
  {"＠type": "City", "name": "Bentonville", "containedInPlace": {"＠type": "State", "name": "Arkansas"}},
  {"＠type": "City", "name": "Rogers", "containedInPlace": {"＠type": "State", "name": "Arkansas"}},
  {"＠type": "Place", "name": "Lake Taneycomo"},
  {"＠type": "Place", "name": "Table Rock Lake"},
  {"＠type": "Place", "name": "the Ozarks"}
]

17 areas total in the final version, blending City (with containedInPlace chaining to State) and Place for non-political geographic features. This is what fuels the discovery for queries like "credit card processing Branson MO" or "ATM placement Eureka Springs AR."

paymentMethod: GoodRelations URIs

This one is criminally underused. Schema.org doesn't have its own enum for payment methods, but it accepts GoodRelations URIs:

"paymentMethod": [
  "http://purl.org/goodrelations/v1#Cash",
  "http://purl.org/goodrelations/v1#Check",
  "http://purl.org/goodrelations/v1#PaymentMethodCreditCard",
  "http://purl.org/goodrelations/v1#DirectDebit",
  "http://purl.org/goodrelations/v1#ByBankTransferInAdvance"
]

Plus a paymentAccepted string field for human-readable variants. Both fields together feed into Google's payment-types facet in the merchant snippet.

Person entities for the founders

Steele Solutions is a husband and wife operation. Both founders get full Person entities in the graph:

{"＠type": "Person", "＠id": "https://steelesolutions4u.com/#jim", ...}
{"＠type": "Person", "＠id": "https://steelesolutions4u.com/#kim", "spouse": {"＠id": "https://steelesolutions4u.com/#jim"}, ...}

Each Person has alumniOf, hasCredential (with recognizedBy linking to the institution's Wikidata QID), knowsAbout, worksFor, memberOf, additionalProperty, and sameAs arrays. Jim's alumniOf chains:

"alumniOf": [{
  "＠type": "CollegeOrUniversity",
  "name": "Indiana University Bloomington",
  "url": "https://www.indiana.edu/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q1079140",
    "https://en.wikipedia.org/wiki/Indiana_University_Bloomington"
  ]
}]

The Wikidata Q-ID is the load-bearing entry. Google's Knowledge Graph reconciles the Person to the institution using the Q-ID, which gives Jim's bio explicit verifiable-entity provenance.

hasCredential with recognizedBy

Most schemas declare credentials as flat strings. The better pattern is EducationalOccupationalCredential with recognizedBy pointing to the awarding institution as its own Organization entity:

"hasCredential": [{
  "＠type": "EducationalOccupationalCredential",
  "name": "First National Bank of Omaha President's Club",
  "credentialCategory": "Sales Performance Award",
  "recognizedBy": {
    "＠type": "BankOrCreditUnion",
    "name": "First National Bank of Omaha",
    "url": "https://www.fnbo.com/",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q5453412",
      "https://en.wikipedia.org/wiki/First_National_Bank_of_Omaha"
    ]
  }
}]

Now the credential is graph-linked to a real Wikidata entity. AI engines and Knowledge Graph can verify Jim's claimed achievement by traversing to the FNBO entity and confirming the institution exists.

sameAs as the verification spine

The org's sameAs array is where third-party verifications live. Steele's includes:

Google Maps CID (for the Google Business Profile)
All 10 partner sites (Electronic Payments, ClearPay, Shift4, etc.)
Wayback Machine archive URL
Taney County, Missouri public real estate records URL
Personal property tax records URL

The Wayback URL is the permanent citation. Live URLs can change. Wayback URLs are immutable. When you put https://web.archive.org/web/20260526012306/https://steelesolutions4u.com/ in your sameAs, you give crawlers a citation that survives even if your site goes down.

What this buys you

Schema density is not a vanity metric. Google's structured data testing tool measures it. AI engines weigh it. Bing's Copilot weighs it heavily.

In Steele's case, the dense schema produced:

Local pack appearance within 7 days of launch for "credit card processing Branson MO"
Position-3 average for the homepage on indexed queries within 14 days
Knowledge Panel sidebar (pending Google Business Profile verification)
AI engine citations on ChatGPT and Perplexity within 21 days of launch

The live example

The complete entity graph is at https://steelesolutions4u.com/entity.json. The schema is also embedded inline on every page of the site so crawlers and AI engines get the full graph regardless of which entry point they hit.

The public verification page at https://steelesolutions4u.com/verification/ cross-references every schema claim with the third-party source backing it.

Tools used

Schema.org for the type definitions
Wikidata for institutional Q-IDs
Internet Archive Wayback Machine for permanent citation URLs
Google Search Console for index status verification
IndexNow for accelerated discovery

The full Steele Solutions resources are public at github.com/Janady13/steele-solutions-resources.