What Is yearsInOperation Schema?

The yearsInOperation schema property describes the operating age of businesses in a BusinessAudience, using a QuantitativeValue to express an exact number, minimum, maximum or range.

Its job is narrow but useful: it identifies how mature the intended business audience is. A grant for companies operating less than two years, a financing service for firms established for at least five years, or a workshop for businesses in years one through three can all have an explicit maturity criterion.

The property does not describe how long the publisher has traded, when an Organization was founded, how old a product is, or how many years a professional has worked. It belongs on BusinessAudience, explained in our BusinessAudience schema guide, where it qualifies the businesses for whom an item was created or offered.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Describe the intended business audience.
• Preserve the page’s exact numeric meaning.
• Omit the property when maturity is not stated.

Primary specification: Schema.org definition for yearsInOperation.

yearsInOperation is an audience qualification field, not a general-purpose company-age field.

Schema.org defines yearsInOperation for BusinessAudience, so it should sit inside a BusinessAudience object rather than directly on Organization, Service, Product or a webpage.

The parent item connects to that audience through the audience property. For example, a Service can have an audience whose type is BusinessAudience, and that nested object can carry yearsInOperation. The relationship tells readers that the maturity value describes the target businesses rather than the service provider.

Direct placement on Organization may parse as generic JSON but gives the property an unsupported home. If the goal is to state when an actual organization began, use its founding information. If the goal is to state which businesses qualify for an offer, use BusinessAudience and yearsInOperation.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the page’s main entity.
2. Confirm the entity has a visible business audience.
3. Nest BusinessAudience under audience.
4. Add yearsInOperation only when the page supports it.

Correct nesting makes the subject of the maturity claim unambiguous.

yearsInOperation defines the desired age of target businesses, while foundingDate records the actual date an Organization was founded; they describe different entities and should not be substituted for one another.

A consultancy founded in 2018 may offer a program only to businesses that have operated for at least three years. Its Organization node can state its own foundingDate, while the program’s BusinessAudience can state a minimum yearsInOperation value of three. Combining those facts would incorrectly make the provider’s age look like a customer requirement or vice versa.

Do not calculate a current company age from foundingDate and publish it as yearsInOperation on that same Organization. Apart from the unsupported placement, the calculated value changes with time and can become stale. Keep dates as dates for real organizations and maturity ranges as audience qualifications.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Ask whose age the statement describes.
• Keep historical dates separate from audience ranges.
• Never infer customer maturity from the provider’s history.

Use foundingDate for a real organization’s origin and yearsInOperation for a target business maturity criterion.

Represent an exact operating-age criterion with a QuantitativeValue containing a numeric value and a clear unit, but only when the page genuinely requires that exact age.

Exact ages are less common than minimums and ranges. A program specifically for businesses in their second year could support a value of two years. A phrase such as “two years or more” is not exact; it should use minValue instead. Encoding it as value 2 would remove the open-ended meaning.

{
  "@type": "BusinessAudience",
  "audienceType": "Businesses in their second year",
  "yearsInOperation": {
    "@type": "QuantitativeValue",
    "value": 2,
    "unitText": "years"
  }
}

Keep numbers as JSON numbers, not decorated strings such as “2+ years.” Descriptive symbols belong in visible copy; the structured object should separate the number and unit.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Read the qualifier around the number.
2. Select value, minValue or maxValue accordingly.
3. Add the matching unit.
4. Compare the rendered markup with the visible sentence.

An exact value is correct only when both ends of the intended interval are the same.

Use minValue for “at least” operating-age requirements and maxValue for “up to” requirements, leaving the unspecified boundary absent rather than inventing a limit.

Open-ended criteria are common in loans, insurance, procurement and accelerator programs. A lender may serve firms operating at least two years, while a startup initiative may serve firms no more than three years old. Each condition has only one justified boundary.

Pay attention to inclusive wording. “More than two years” and “at least two years” are not mathematically identical, but many business pages use rounded-year qualification. The structured representation must reflect the rule the business actually applies. If the operational policy is unclear, fix the visible statement before making the markup more precise.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Preserve open boundaries.
• Document whether threshold years are inclusive.
• Align public copy, eligibility logic and JSON-LD.

One supported boundary is more accurate than a complete-looking range built from assumptions.

Use minValue and maxValue together when the target audience has a published lower and upper operating-age boundary, and express both values in the same unit.

A program for companies operating one to five years can use a minimum of one and maximum of five with unitText “years.” Do not mix months and years in a single range without first normalizing them. If the page says 18 months to three years, choose one consistent unit and make sure the conversion preserves the rule.

Ranges should remain attached to the correct audience. If a page has separate tracks for new and established companies, model distinct BusinessAudience objects only when each audience is meaningfully connected to the relevant offer or content. Avoid merging two disjoint groups into one broad range that includes businesses the page excludes.

"yearsInOperation": {
  "@type": "QuantitativeValue",
  "minValue": 1,
  "maxValue": 5,
  "unitText": "years"
}

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm both boundaries are visible.
2. Normalize to one unit.
3. Validate boundary order.
4. Recheck every variant created by the template.

A valid operating-age range must preserve the same interval and unit the visitor sees.

Use a consistent unit with yearsInOperation; unitText is a clear practical choice for “years,” while a suitable standard unitCode may be used when the implementation already manages standardized measurement codes.

Schema.org allows QuantitativeValue to carry unitText or unitCode. The main SEO quality issue is not which valid unit field looks more technical, but whether the numeric meaning is clear, consistent and supported. A bare range of 1–5 leaves consumers to infer whether it means years, months or another period.

Use one policy across the site. If the content system stores years, emit years. If qualification logic stores months, decide whether the visible page and markup will also use months or whether both will be converted. Do not convert only the markup, because reviewers will struggle to compare it with the displayed criterion.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Choose a sitewide unit policy.
• Keep boundaries in the same unit.
• Test conversion rules with boundary examples.

Unit consistency makes an operating-age value auditable and prevents silent conversion errors.

Common mistakes include placing the property on Organization, using it for the provider’s age, converting vague maturity labels into exact numbers, dropping units and leaving old eligibility thresholds in templates.

A syntactically valid QuantitativeValue can still communicate a false relationship. Validators check whether fields are shaped correctly; they do not know whether the number describes a customer segment, the provider, or an internal lead score. Editorial evidence and entity context are therefore essential.

Another mistake is deriving years automatically from a target company’s founding date. BusinessAudience normally describes a class of businesses, not a specific organization. An eligibility range should come from the page’s public targeting rule, not from data enrichment or a CRM estimate that visitors cannot verify.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Check the property’s subject.
2. Verify every boundary against visible copy.
3. Reject inferred or private maturity data.
4. Trace repeated errors to the generator.

Semantic correctness depends on the audience relationship and evidence, not just a passing parser.