Project pages: separate useful facts from structured data

A project page needs useful, visible facts before it needs more structured data. Explain what was delivered, the team’s actual role, and which evidence is available. Markup can describe that record; it cannot turn an unsupported result into a fact or guarantee a special search appearance.

For portfolio SEO, distinguish three questions: is the page useful, does its markup accurately describe it, and does a search engine support a relevant result feature? Those questions have different answers and different tests.

Establish the project record first

Use a consistent editorial record for client or product name, delivery scope, relevant technology, and approved media. Keep the project year separate from the publication and update dates of the written account. A portfolio article published later does not move the delivery into a different year.

For example, the confirmed 2024 scope for LearningWell identifies a Next.js frontend with a WordPress backend. That supports a precise technology statement. It does not establish why that architecture was selected or what commercial effect it had.

If a decision rationale is documented and approved, explain it. Otherwise keep the technology fact and leave the rationale unstated. Buyers can distinguish a limited account from a confident invention.

Choose vocabulary without inventing eligibility

Schema.org defines CreativeWork as a broad vocabulary type. A vocabulary choice is not, by itself, a Google rich-result feature. Check Google’s supported structured-data gallery for the specific feature being proposed.

Do not relabel a project as a purchasable product merely to pursue a search treatment. Likewise, an internal project review is not a customer rating to manufacture into aggregate review markup.

Where the page has a genuine breadcrumb trail, Google’s breadcrumb documentation provides the feature requirements. Evaluate that separately from whatever vocabulary describes the project itself.

Work through a hypothetical markup review

Imagine a hypothetical agency page describing a bilingual catalog implementation. Its visible text states the scope and includes approved screenshots, but has no measured business results.

The proposed JSON-LD adds a revenue claim and a rating that appear nowhere on the page. Reject those properties. Google’s structured-data policies require markup to represent visible content and do not guarantee rich-result display even when markup is valid.

Use this review before technical validation:

Question	Decision
Is the fact visible and approved?	Include it only if it also fits the chosen vocabulary
Is it merely an inference from a screenshot?	Verify it or leave it out
Does it describe the client rather than the agency?	Keep the entities and their roles distinct
Is a property being added only to satisfy a validator?	Do not invent a value

This is an illustrative review, not a description of an existing 5e Labs page.

Validate meaning as well as syntax

Inspect the generated HTML and JSON-LD together. Technical validation can catch malformed data, but an editor must still judge whether the description is honest. Passing a test does not prove the underlying project claim.

Repeat the content comparison for Spanish. Project identities should remain consistent, while descriptions should match the language and facts of the visible page.

Before requesting additional portfolio markup, prepare one project record with approved scope and media. A 5e Labs web development review can then separate missing content from template work and any genuinely applicable search feature.