Structured Data for Company Websites: The Complete Implementation Guide

Your company website tells humans who you are. Structured data tells machines. Without structured data, Google treats your website as a collection of pages. With it, Google treats your website as a declaration of entity identity.

This distinction is not academic. It is the difference between having a Knowledge Panel and not having one. Between being cited by AI and being ignored. Between passing a procurement team's due diligence check and failing it silently.

This guide covers the complete implementation of structured data for a company website. Every schema type you need, the code to implement it, and how to validate that it works. I use these exact patterns on my own sites and in entity infrastructure projects for clients.

How structured data flows through the system

Before diving into code, understand the pipeline. Structured data on your website is one input into a larger system.

Structured data is one input. Google cross-references it with external sources before generating a Knowledge Panel or feeding AI systems.

Organization schema: the foundation

Every company website needs Organization schema on the homepage. This is the single most important piece of structured data you will implement. Here is the complete template:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourcompany.com/#organization",
  "name": "PT Your Company Name",
  "alternateName": "Your Company",
  "url": "https://yourcompany.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://yourcompany.com/images/logo.png",
    "width": 600,
    "height": 60
  },
  "description": "One or two sentences describing what the company does.",
  "foundingDate": "2008",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Jl. Your Street No. 123",
    "addressLocality": "Bogor",
    "addressRegion": "West Java",
    "postalCode": "16111",
    "addressCountry": "ID"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+62-251-1234567",
    "contactType": "customer service",
    "availableLanguage": ["Indonesian", "English"]
  },
  "sameAs": [
    "https://www.linkedin.com/company/yourcompany/",
    "https://www.wikidata.org/wiki/Q123456789",
    "https://www.instagram.com/yourcompany/",
    "https://www.facebook.com/yourcompany/"
  ],
  "knowsAbout": [
    "industrial engineering",
    "pump systems",
    "fabrication"
  ],
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "minValue": 10,
    "maxValue": 50
  },
  "iso6523Code": "0060:1234567890"
}
</script>

Let me explain the non-obvious properties:

@id: A unique identifier for this entity within your site. Use the format https://yoursite.com/#organization. This allows other schema blocks on your site to reference this entity without repeating all its properties.

sameAs: An array of URLs for your verified external profiles. Every URL in this array should link back to your website. As discussed in strategic schema markup, this bidirectional linking is how Google confirms identity across platforms.

knowsAbout: Topics your organization has expertise in. This helps AI systems associate your entity with relevant queries. Use specific, factual terms rather than marketing language.

numberOfEmployees: Use a range if you prefer not to state an exact number. This is optional but helps Google categorize your company size.

Person schema: key people

For companies where the founder or director is a significant part of the brand (which is most mid-market B2B companies), add Person schema on the about or team page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://yourcompany.com/#founder",
  "name": "Your Name",
  "jobTitle": "Director",
  "worksFor": {
    "@id": "https://yourcompany.com/#organization"
  },
  "url": "https://yourpersonalsite.com",
  "sameAs": [
    "https://www.linkedin.com/in/yourprofile/",
    "https://orcid.org/0000-0000-0000-0000",
    "https://www.wikidata.org/wiki/Q987654321"
  ],
  "knowsAbout": [
    "entity infrastructure",
    "industrial engineering",
    "book conservation"
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "ISO 9001:2015 Lead Auditor"
    }
  ]
}
</script>

The worksFor property uses @id to reference the Organization schema declared on the homepage. This creates a linked data relationship: Person works for Organization. Google can now model this relationship in its entity graph.

For a deeper dive into Person schema implementation, see the JSON-LD Person schema guide.

Article schema: for published content

If your company publishes articles, case studies, or blog posts, each should have Article schema. This connects your content to your entity, establishing authorship and organizational affiliation:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article Title Here",
  "description": "Brief description of the article.",
  "datePublished": "2026-05-14",
  "dateModified": "2026-05-14",
  "author": {
    "@id": "https://yourcompany.com/#founder"
  },
  "publisher": {
    "@id": "https://yourcompany.com/#organization"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://yourcompany.com/articles/article-slug/"
  }
}
</script>

The author and publisher both reference entities declared elsewhere on your site using @id. This is cleaner than repeating the full Organization and Person data in every article. The Article schema essay covers additional properties and edge cases.

WebSite schema: search and navigation

If your site has a search function, add WebSite schema. This can enable a sitelinks search box in Google results:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Your Company Name",
  "url": "https://yourcompany.com",
  "publisher": {
    "@id": "https://yourcompany.com/#organization"
  },
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://yourcompany.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

BreadcrumbList schema: navigation context

Add breadcrumb schema to every interior page. This helps Google understand your site structure and can produce breadcrumb-style navigation in search results:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://yourcompany.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Services",
      "item": "https://yourcompany.com/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Pump Systems",
      "item": "https://yourcompany.com/services/pump-systems/"
    }
  ]
}
</script>

The implementation checklist

Common implementation mistakes

Duplicate Organization schema. If your CMS automatically generates Organization schema and you manually add your own, you have two conflicting declarations. Google may use either one, or neither. Check your page source for duplicates before adding new schema.

sameAs pointing to dead URLs. Profile URLs change. LinkedIn restructures its URL format. Instagram accounts get deleted. Every URL in your sameAs array must resolve to an active page. Check quarterly.

Using marketing language in schema. Your Organization description should be factual: "Indonesian industrial engineering company specializing in pump systems." Not: "Indonesia's most trusted and innovative engineering partner delivering world-class solutions." Schema is for machines, not humans. Marketing language in schema fields is wasted at best and suspicious at worst.

Forgetting to connect schema across pages. Organization on the homepage, Person on the about page, Article on blog posts. If these do not reference each other using @id, they are isolated declarations. Google cannot build a connected entity model from disconnected schema blocks.

Not validating after deployment. As covered in the structured data validation guide, deploying schema without testing is like filing a government form without checking the fields. Use the Rich Results Test on every page that has structured data.

Testing and validation

After implementing structured data:

1. Validate JSON syntax. Paste each JSON-LD block into a JSON validator to catch syntax errors.
2. Check schema compliance. Use the Schema Markup Validator at validator.schema.org to verify your types and properties are correct.
3. Test with Google. Run the Rich Results Test on each page URL (not raw code) to see what Google actually reads.
4. Monitor in Search Console. Check the Enhancements report weekly for the first month after deployment to catch any issues Google flags.
5. Verify sameAs bidirectional links. Visit every URL in your sameAs array and confirm it links back to your website. This closed loop is what converts declarations into verification.

Structured data is infrastructure, not decoration. Implement it once, validate it regularly, and it works silently in the background making your company verifiable to every machine that encounters it. Google, AI systems, procurement databases, and whatever comes next.

For companies that want this implemented professionally, the entity infrastructure practice handles the full stack from schema implementation through Wikidata setup to ongoing validation. For teams building it themselves, the course library includes hands-on implementation modules with code examples and validation checklists.