Weave Code
Schema Org Laravel Package
spatie/schema-org
spatie/schema-org is a fluent PHP builder for all Schema.org types and properties, generated from the official vocabulary. Chain methods to construct structured data and output valid ld+json script tags for rich search results.
spatie/schema-org is a fluent PHP builder for all Schema.org types and properties, generated from the official JSON-LD standards file so the entire core vocabulary is covered. Chain readable methods to create rich structured data, then render it as a ready-to-use <script type="application/ld+json"> block for better SEO.
$localBusiness = Schema::localBusiness()
->name('Spatie')
->contactPoint(Schema::contactPoint()->areaServed('Worldwide'));
echo $localBusiness->toScript();
- Complete vocabulary — objects and methods for every Schema.org type
- Fluent, chainable API with IDE-friendly autocompletion
- Nested types supported via nested builder calls
- Automatic ld+json generation with correct
@contextand@type - Fully documented classes and methods as a quick reference
Frequently asked questions about Schema Org
- How do I install spatie/schema-org in a Laravel application?
- Install it with Composer by running composer require spatie/schema-org. There is nothing else to configure: no service provider, config file, migration, or facade registration is needed. You can immediately use the Spatie\SchemaOrg\Schema factory from controllers, API resources, jobs, or Blade components. For most Laravel projects it is a single dependency with no infrastructure impact.
- Does spatie/schema-org need a Laravel service provider or config file?
- No. The package is framework-agnostic and deliberately ships without a Laravel service provider, config, or facade. That keeps it composer-friendly and avoids lifecycle hooks in your application bootstrap. You simply call the static Schema factory or instantiate generated type classes directly. If you want Laravel-idiomatic encapsulation, wrap it in your own service class or Blade component.
- Which Laravel and PHP versions does spatie/schema-org support?
- The package targets PHP 8.x and fits Laravel 9 through 11 without adapters. PHP 8.3 test coverage landed in version 3.15.0, so check your pinned release if you run the newest PHP runtime. Always confirm the require constraints on Packagist for the exact version you install. Because it is framework-agnostic, Laravel version is rarely the limiting factor.
- How do I render Schema.org JSON-LD in a Blade template?
- Build the entity with the fluent API and echo the result of toScript(), which returns a complete script tag with type application/ld+json. Call toScript() once per graph and place it in your layout head section. If you prefer raw data, toArray() or json_encode() gives you an array or string for API resources and Inertia props. Remember that the package returns markup as a string, so output it unescaped in Blade.
- How do I combine Organization, WebSite, and Product markup on the same page?
- Use Schema::graph() to register multiple entities and link them with @id references, so search engines can resolve the relationships. A common pattern is a layout-level graph for Organization, WebSite, and SearchAction, plus a page-level graph for Product, Offer, AggregateRating, and BreadcrumbList. MultiTypedEntity lets a single node carry multiple types, though its properties are merged with array_merge, so duplicate property names resolve last-writer-wins. Define internal conventions for which graph owns each @id to avoid conflicting definitions.
- Does spatie/schema-org validate my structured data against Google's Rich Results requirements?
- No. The package serializes exactly what you give it and performs no validation of property cardinality or Google-specific rich result rules. Invalid markup will fail silently in production because nothing throws on missing recommended properties. Build a validation gate yourself using the Schema Markup Validator, the Google Rich Results Test, or CI fixture assertions on your generated JSON. Treat correctness of the data model as an application concern, not a package concern.
- How do I add a Schema.org property that the package doesn't support?
- Use setProperty() and getProperty() as an escape hatch on any generated type, passing the raw vocabulary property name and value. This covers vocabulary added after the schema.org release your pinned version was generated against, currently v24 in 3.23.0. Note that Schema::float() is unavailable because Float is a PHP reserved keyword, so use setProperty or a different numeric type where needed. Keep a list of these manual properties so you can migrate them when a release adds native support.
- How can I test JSON-LD output in a Laravel test suite?
- Assert on toArray() output rather than the rendered script string, so escaping and whitespace do not break your tests. Typical assertions check @type, @context, @id links, nested entities, and required properties for the rich result you target. You can also snapshot the generated graph for regression detection when upgrading the package. For end-to-end coverage, fetch the page and parse the ld+json block with json_decode to confirm it is valid JSON.
- How often is spatie/schema-org updated for new schema.org releases, and is upgrading risky?
- Recent minor releases have moved quickly through schema.org versions, from v17 to v24, so expect periodic vocabulary bumps. Upgrades are additive by design but can rename or shift property semantics, and identifier handling changed from identifier to @id back in v2.6. Treat each upgrade as a reviewable event: run your fixture assertions and compare generated output before merging. Pin a version and document the schema.org release it targets so migrations stay predictable.
- Why should I use spatie/schema-org instead of writing JSON-LD by hand or another package?
- It generates classes and methods from the official schema.org JSON-LD vocabulary, so coverage of the core vocabulary is effectively complete rather than hand-maintained. The fluent API and Graph abstractions remove string-concatenation bugs and make cross-page entity linking with @id practical. The trade-offs are no built-in validation and no full API reference, so onboarding relies on reading the source or schema.org itself. For Laravel teams wanting a small, framework-agnostic dependency that outputs plain JSON-LD strings or arrays, it is usually the lowest-friction option.
Weaver
How can I help you explore Laravel packages today?