What Is Course Schema?

The Course type describes the curriculum itself: its name, description, provider, prerequisites, outcomes and credentials. A CourseInstance can represent a particular cohort, schedule, location, instructor or delivery mode. A Course list uses ItemList to organize several course entities for discovery.

Markup does not turn a short video, sales webinar, public event or article into a course. It cannot verify instruction quality, accreditation or learning outcomes. The visible program, enrollment process and provider evidence must support every educational claim.

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.

• Model a real curriculum with learning outcomes.
• Separate the course from each scheduled offering.
• Ground provider and credential claims in records.

Primary specification: Schema.org definition for Course.

Course schema describes a genuine structured learning program, not any content that teaches one isolated fact.

A parser reads the Course name, short description and provider, then follows list or instance relationships. An ItemList can enumerate course URLs in a stable order. A CourseInstance can identify when and where the curriculum is delivered, its instructor, mode and offer.

Syntax validation cannot prove that students enroll, instructors lead the program or a credential is recognized. The catalog, learning-management system, enrollment system and institutional policy remain authoritative. Template output should follow those sources rather than duplicate manually maintained marketing fields.

• 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 the content meets the course definition.
2. Create a stable curriculum identity.
3. Map provider, outcomes and prerequisites.
4. Connect current course instances.
5. Validate catalog and enrollment paths.

The graph works when one stable curriculum connects to truthful providers, learning details and current offerings.

An SEO fundamentals curriculum can remain the same across spring and fall cohorts. Each cohort can differ by instructor, start date, location or online mode and therefore becomes a CourseInstance. A one-hour public SEO webinar is usually an Event rather than a Course when it lacks a curriculum sequence and roster.

Self-paced courses can still have an instance or offer context when learners enroll and complete a structured program. A single tutorial article or two-minute video remains content, not a Course, even when educational.

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.

• Separate reusable content from delivery.
• Do not label every webinar a course.
• Use content types for isolated lessons and guides.

Use Course for curriculum, CourseInstance for a particular offering and Event for scheduled experiences without a full course structure.

Current Course list documentation requires a name and description for each represented course and uses provider as a supported high-value field. Course titles should contain only the real curriculum name, not prices, discounts or “best course” claims. Descriptions should state the subject and outcome concisely.

The provider should be the organization that delivers the source course content, connected through Organization schema. Add credentials only when the institution actually awards them under a documented policy.

• 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. Use the canonical course name.
2. Write a specific learning description.
3. Reference the real provider.
4. Add catalog and prerequisite facts.
5. Connect only genuine credentials and instances.

Start with a clear course identity, concise learning description and real provider before adding credentials, instances or catalog detail.

The list can live on a summary page that links to course detail pages or on one all-in-one page with anchored course sections. Positions should reflect a stable visible order, not personalization or paid placement hidden from users. Each URL must identify the corresponding course.

A detail page used in the course list should contain its Course data and be paired with the list architecture. Search and filter pages are poor sources when their order and contents change by session. Feature eligibility does not guarantee a displayed list.

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.

• Publish at least three qualifying courses.
• Keep positions and URLs visible and stable.
• Pair list pages with complete detail pages.

A valid course list is a stable visible collection of at least three real courses with ordered unique destinations.

Two cohorts of the same curriculum may have different dates, instructors or tuition and should not overwrite one another. Online, in-person and blended delivery need accurate courseMode and location context. A self-paced instance can state its real access pattern without inventing fixed class dates.

Enrollment windows, capacity and pricing belong to the offering or instance context. Do not leave a past cohort marked open because the curriculum remains available. Connect instructors through real Person profiles only when they actually lead that instance.

• 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. Separate curriculum from scheduled delivery.
2. Assign real mode, dates and location.
3. Connect current instructor and language.
4. Map enrollment offer and capacity.
5. Close past instances promptly.

CourseInstance keeps time, place, instructor and enrollment facts out of the reusable curriculum identity.

A marketplace that hosts third-party courses is not always the provider of each curriculum. Distinguish the platform, institution and instructor from operational evidence. Instructor biographies should avoid invented expertise and connect to ProfilePage identities when profiles exist.

A completion badge, attendance certificate, academic credit and professional credential are different outcomes. Use educationalCredentialAwarded or related properties only when the named award is real and the public page explains its issuer and conditions.

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.

• Separate platform, provider and instructor.
• Connect teaching roles to real instances.
• Describe credentials and credit precisely.

Course authority should come from truthful provider, instructor and credential relationships rather than promotional titles or fabricated accreditation.

Catalog templates can create duplicate Course IDs for each cohort, fragmenting one curriculum. The opposite problem merges distinct programs under one generic identity. Personalized lists may output unstable positions and URLs that require login.

Educational claims require particular care. Markup should not imply accreditation, guaranteed employment, transferable credit or professional licensing without evidence. Validation cannot test instructional quality or legal recognition.

• 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 each item meets the course definition.
2. Reconcile Course and CourseInstance IDs.
3. Verify provider and instructor roles.
4. Audit list count, order and URLs.
5. Test credentials and enrollment status.

Course markup fails when curriculum, provider, credential, list or enrollment facts are exaggerated, merged or stale.