Is your page eligible for review stars?

Start with eligibility before discussing installation. Google's supported review features include products, books, recipes and software apps. Local businesses and organizations have additional restrictions, so check the supported types and guidelines against your chosen page.

The business homepage problem

A business-controlled page reviewing that same business is ineligible for stars through LocalBusiness or Organization markup. Embedding an outside review widget does not remove that restriction. Google states this in its self-serving review rules.

Hypothetical example: a neighbourhood bakery wants stars beneath its homepage result. I would first ask the owner to separate the customer testimonial project from the search appearance project. Keep useful testimonials in the website brief, but remove any promise that adding a review widget will produce homepage stars.

A specific product is a different starting point

Hypothetical example: a kitchenware shop wants to work on one coffee grinder's product page. Ask the team to collect information about that grinder, rather than combine comments about delivery, customer service and unrelated purchases.

For the surrounding product information, use the product schema setup guide. Keep the first assignment small enough that someone can inspect every review and explain what each field represents.

What do Review and AggregateRating actually mean?

Think of the labels as answers to ordinary questions. What was reviewed? Who wrote the review? What score did they give? This is a useful way to discuss the work without learning programming.

Review describes an evaluation of a particular item. Schema.org defines itemReviewed as the reviewed item, reviewBody as the written review and reviewRating as its rating. Check those meanings in the Review definition.

AggregateRating describes an overall rating based on several reviews or ratings. A review snippet is the short review or rating summary Google may display in search. The data and the displayed result are different things, as the review snippet guide shows.

Structured data helps Google understand what page content means. A rich result is a search result with additional information or presentation features. Google's structured data introduction explains that relationship.

Ask your provider to point to one customer review and then its matching data. Repeat the exercise for the overall rating. You should be able to follow the connection without reading the whole code file.

What should you prepare before adding markup?

Create a short review inventory for one page. I suggest doing this in a shared document that both the store manager and website provider can read. Record the information you have and mark anything that still needs checking.

• The exact item being reviewed and its page address.
• The original review text and reviewer identity.
• The rating supplied with that review.
• The source record your team can check.
• The person responsible for updates and corrections.

Marked-up reviews and aggregate ratings must be visible to visitors. Multiple individual reviews should also have an aggregate rating, and Google says not to combine reviews from other websites into that aggregate. See the technical guidelines.

Write a collection request your team can reuse

Hypothetical example: an independent stationery shop asks buyers what they thought of a particular notebook. In your request, name the notebook and invite an honest description of using it. Avoid writing the customer's answer for them.

For a separate Google review collection project, continue with the guide to getting more Google reviews. Keep that assignment clearly labelled so your team does not confuse it with preparing product review information for your own website.

Before handover, choose a review at random and trace it back to its original record. If the team cannot explain where it came from, resolve that question before including it in the pilot.

How should you brief the person building it?

Give your provider a page address, your review inventory and a clear acceptance checklist. Ask them to explain the connection between the visible content and the generated data. Do not accept a plugin name as the whole delivery.

Use this table to discuss the fields. Their meanings come from Schema.org's Review vocabulary and Google's rating property definitions.

A review schema markup example to discuss

The outline below is a planning example, not installable code. Replace the bracketed descriptions with your records when briefing your provider. It shows which information belongs together without inventing customers or scores.

Product
  name: [specific product]
  review:
    Review
      author: [reviewer]
      reviewBody: [review text]
      reviewRating: [individual rating]
  aggregateRating:
    AggregateRating
      ratingValue: [average rating]
      ratingCount: [number of ratings]

Google provides working examples of reviews and aggregate ratings nested inside products in its implementation documentation. Ask your provider to adapt the relevant example to your actual content and test it.

Use the website system you already have

Google notes that systems such as WordPress, Shopify and Wix may offer settings or plugins for structured data. Review the CMS guidance, then ask what your existing setup already produces.

For handover, request the finished page, the test output and a short update procedure. Ask who will investigate if a future website change alters the review display. Put that person's name in the maintenance notes.

What should you check when stars do not appear?

Separate the investigation into content, technical access and eligibility. Start with what you can directly verify. Keep a written record of each issue so the next person does not have to reconstruct your investigation.

Google recommends Rich Results Test for validating the implementation and URL Inspection in Search Console for checking the published page. Its setup guidance also identifies robots.txt, noindex and login requirements as possible access barriers. Follow the official testing sequence.

1. Read the page. Find the item name, reviews and overall rating as a visitor would.
2. Run the test. Send the exact critical error messages to your provider.
3. Inspect the live address. Confirm you are checking the intended page.
4. Revisit eligibility. Check what is reviewed and who controls the page.
5. Document the correction. Record the change, owner and next check.

Put wider website problems into a practical SEO audit. For the business discussion afterwards, use the SEO report reading guide to frame the questions you want answered.

What can you realistically finish this week?

Set a delivery target you control: one suitable page with traceable review information and documented testing. Do not make a screenshot of search stars the acceptance condition. I would assign the work as follows.

• Owner: choose the item and approve the scope.
• Customer service: prepare the review records.
• Website provider: implement and test the data.
• Marketing: read the finished page and keep the handover notes.

At the review meeting, ask someone who did not build the page to find the rating and explain what it covers. Then trace one displayed review back to its record. Resolve any mismatch before extending the setup.

Also review the purchase decision itself: does the page answer the questions you would ask before buying? Continue that work with the conversion rate optimization guide. Keep the review implementation and the broader page improvements as separately assigned tasks.