Skip to content
50% OFF $299 $599
Lock in
§ 4.2.4 ARTICLE
Published Verified Every 6 weeks Sources 5 named Authored by SquareRank Team

Lawyers · § 4.2.4 · How-to · Schema

Attorney LegalService Schema for Squarespace

The 2026 attorney schema install ships two blocks: LegalService on the firm’s homepage and Person on each attorney’s bio page, joined through the LegalService’s employee array and the Person’s worksFor property. The deprecated Attorney type2 still validates but is recommended against by Schema.org’s own documentation. The LegalService + Person pattern is the cleaner entity graph and the one Google and the AI engines walk most reliably.

This leaf ships the production JSON-LD blocks: the firm-level LegalService with multi-office expansion, the per-attorney Person with knowsAbout, alumniOf, memberOf, and sameAs filled in, and the cross-references that join them into one entity graph the search engines can walk from any starting point.

TL;DR — LegalService for the firm, Person per attorney, no Attorney type

The minimum-viable boutique-firm schema install is two block types. The LegalService block lives on the homepage (and on each office page for multi-office firms) and carries the firm's name, address, telephone, areaServed, serviceType, and an employee array referencing the attorneys. The Person block lives on each attorney's bio page and carries name, jobTitle, image, knowsAbout (practice areas), alumniOf (law school), memberOf (bar associations), worksFor (the firm), and sameAs (directory profiles, LinkedIn, state bar listing). The blocks reference each other by @id so the search engines see one entity graph instead of two unconnected schemas.

The install is gated to Squarespace’s Business plan or above because Code Injection is locked off below that. Personal plan sites cannot ship LegalService or Person markup — which is the single biggest gap on a Personal plan boutique-firm site, and the first reason to upgrade. The upgrade decision is roughly $11/mo extra at the annual rate at time of writing; for a YMYL legal site the schema layer is not optional.

Why Attorney is deprecated and what to use instead

Schema.org defines Attorney as 'a type of LegalService' and its documentation has long recommended LegalService as the more inclusive and less ambiguous type. The Attorney type is retained for backward compatibility with sites that adopted it before LegalService matured, but it provides no distinct rich-result behaviour and no signal to search engines that LegalService does not also provide. The 2026 best-practice install is LegalService for the firm entity and Person for each attorney — never Attorney.

The schema.org community discussed this ambiguity at length in 2017 and 2018: the Attorney type conflates the firm and the individual practitioner, which makes it hard for downstream consumers (search engines, AI engines, directory crawlers) to tell whether the marked-up entity is the law firm, the senior partner, or an associate. LegalService + Person resolves the ambiguity by separating the firm (a business entity) from each attorney (an individual professional). The deprecation is not a removal — existing Attorney markup still validates — it is a recommendation against new use.

The schema.org documentation for Attorney2 notes the deprecation in the type description itself. The recommended replacement pattern is LegalService for the firm1 joined to one Person3 per attorney through the LegalService’s employee property (or founder for founding partners). The pattern below is the production version.

The LegalService block — firm-level JSON-LD

The LegalService block describes the firm as a business. It lives on the homepage and on each office page for multi-office firms. The block carries name, url, telephone, address as a PostalAddress, areaServed as an array of strings or AdministrativeArea objects, priceRange as a $-symbol shorthand or a price band, openingHoursSpecification, serviceType as the practice area array, and employee as the array of attorney references. The @id is the firm's canonical identifier — typically the homepage URL with a fragment — and is what the attorney Person blocks reference back through worksFor.

JSON-LD Production LegalService block — paste on the firm's homepage (Code Injection > Header) 
 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "LegalService", "@id": "https://hartwellcole.com/#legalservice", "name": "Hartwell & Cole, LLP", "url": "https://hartwellcole.com", "telephone": "+1-415-555-0142", "priceRange": "$$", "image": "https://hartwellcole.com/assets/logo.png", "address": { "@type": "PostalAddress", "streetAddress": "500 Sansome St, Suite 700", "addressLocality": "San Francisco", "addressRegion": "CA", "postalCode": "94111", "addressCountry": "US" }, "areaServed": ["San Francisco", "Alameda County", "San Mateo County"], "serviceType": ["Estate Planning", "Trust Administration", "Probate Litigation"], "openingHoursSpecification": { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "09:00", "closes": "17:30" }, "employee": [ { "@id": "https://hartwellcole.com/attorneys/anjali-hartwell/#person" }, { "@id": "https://hartwellcole.com/attorneys/marcus-cole/#person" } ] } </script>

The block follows Google’s LocalBusiness recommendations4 for the inherited LocalBusiness properties (name, address, telephone, openingHoursSpecification) and adds the legal-specific shape on top: serviceType for the practice area array, employee for the attorney references by @id. The priceRange is the standard $-symbol shorthand — $ for low-cost, $$ for moderate, $$$ for premium. Most boutique firms land at $$ or $$$ depending on practice area.

The Person block — per attorney

Each attorney gets a Person block on the attorney's own bio page. The block carries name, jobTitle, url, image, knowsAbout (the practice areas the attorney handles), alumniOf (law school as an EducationalOrganization), memberOf (bar associations as an array of Organization references — one per bar admission), worksFor (the firm's LegalService by @id), and sameAs (an array of verifiable third-party profiles including Avvo, Justia, Martindale-Hubbell, LinkedIn, and the state bar's public attorney lookup). The @id on the Person block matches what the LegalService's employee array references.

JSON-LD Production attorney Person block — paste on /attorneys/[firstname-lastname]/ (Code Injection > Header) 
 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Person", "@id": "https://hartwellcole.com/attorneys/anjali-hartwell/#person", "name": "Anjali Hartwell", "jobTitle": "Founding Partner", "url": "https://hartwellcole.com/attorneys/anjali-hartwell/", "image": "https://hartwellcole.com/assets/anjali-hartwell.jpg", "knowsAbout": ["Estate Planning", "Trust Administration", "California Probate Code"], "alumniOf": { "@type": "EducationalOrganization", "name": "UC Berkeley School of Law" }, "memberOf": [ { "@type": "Organization", "name": "State Bar of California" }, { "@type": "Organization", "name": "American Bar Association" } ], "worksFor": { "@id": "https://hartwellcole.com/#legalservice" }, "sameAs": [ "https://www.avvo.com/attorneys/example", "https://www.justia.com/lawyers/example", "https://www.martindale.com/attorney/example", "https://www.linkedin.com/in/example", "https://apps.calbar.ca.gov/attorney/Licensee/Detail/000000" ] } </script>

Three notes on the block. First, the memberOf array is the bar-admissions list — one Organization entry per bar the attorney is admitted to. An attorney admitted in California, New York, and the Northern District of California shows three entries: the State Bar of California, the New York State Bar, and the U.S. District Court for the Northern District of California. Second, alumniOf is the law school; for attorneys with relevant additional degrees (an LL.M., a JD/MBA), the property accepts an array of EducationalOrganization objects. Third, the state bar attorney-lookup URL in sameAs is the strongest YMYL trust signal in the block — it lets search engines verify the named attorney exists in the named jurisdiction with the claimed bar number.

The attorney Person block, in numbers

5

minimum sameAs entries for an attorney Person — directory profiles + state bar lookup + LinkedIn.

Google Search Central · 2026
1+

memberOf entry per bar admission — one Organization object per jurisdiction the attorney is admitted in.

Schema.org · 2026
0

Attorney-type blocks on a 2026 install — replaced entirely by LegalService for the firm and Person per attorney.

Schema.org · 2026

Joining LegalService to Person — the entity graph

The two block types reference each other by @id. The LegalService's employee array contains lightweight references to each attorney Person (just {@id: '…#person'} per attorney). Each attorney Person's worksFor property contains a lightweight reference to the LegalService (just {@id: '…#legalservice'}). Search engines walking the graph from either entry point — the homepage or any attorney bio — resolve the cross-references and arrive at the same picture of who works at the firm and in what capacity.

The cross-reference pattern matters because it lets each page carry only the schema it needs. The homepage carries the LegalService with employee references, not the full Person blocks for every attorney. Each attorney’s bio page carries that attorney’s full Person block, not the full firm details. The search engines and AI engines stitch the picture together by following the @id references. The alternative — inlining every attorney’s full Person block on the homepage and every firm detail on every attorney page — works but creates a maintenance burden: every change to any attorney has to be propagated to every page that carries the inlined block.

For a multi-office firm, the same pattern extends naturally. Each office page carries a LegalService block with its own @id (typically the office URL plus a fragment) and its own employee array listing the attorneys assigned to that office. The homepage’s LegalService block is the firm-wide entity; the per-office LegalService blocks are branch entities that share the firm name but have distinct addresses. The pattern follows Google’s multi-location LocalBusiness recommendation4.

Where the JSON-LD lives on a Squarespace site

On Squarespace 7.1, JSON-LD lives in Code Injection. The site-wide layer goes in Settings > Advanced > Code Injection > Header — but the LegalService and Person blocks are page-specific and belong in the per-page injection slot at Page Settings > Advanced > Code Injection > Header. Code Injection is gated to Business plan or above ($23/mo on annual at writing); Personal plan sites cannot install the schema layer at all, which is the single biggest gap on a boutique-firm Personal-plan site and the first reason to upgrade.

The page-level injection slot is the right home for these blocks because each page has its own canonical schema. The homepage carries the firm-level LegalService; each office page carries an office-level LegalService; each attorney bio carries that attorney’s Person; each practice-area page carries a Service block (covered in the practice area pages leaf). Putting all of them in the site-wide header slot would emit every schema block on every page, which validates but is noisy and obscures the canonical-per-page pattern the search engines prefer.

Validate every block in Google’s Rich Results Test after pasting and after every edit. The validator surfaces structural errors (missing required properties, invalid type references) and warnings (missing recommended properties). For a YMYL legal site, the recommended-properties warnings should be treated as required — missing image, missing telephone, or missing openingHoursSpecification on a LegalService block weakens the entity signal even though the block validates. The discipline that ships the rest of the install applies here too: ship the full block, validate it, refresh quarterly.

Keep reading · § 4.2.4