How Displaying Google Reviews on Websites Works: Methods and Rules

A practical guide to displaying Google reviews on your website without guesswork — consumer map embeds vs Maps Embed API vs Places API Place Details vs Business Profile API, the Places API five‑review limit, and an implementation playbook that keeps your display aligned with the rules of the source surface.

Sev LeoLinkedInTwitter

Founder and sole developer of ShowTrust.to and Skribra.com

Start with the source

To display Google reviews on website, start by naming the Google “surface” you’re pulling from. An embed (consumer or Maps Embed API) renders a Google-controlled Maps view, not a review feed you can reshape. A developer API (Places API or Google Business Profile APIs) can return review data, but it comes with hard limits and required ways to present it.

Consumer map embed

Google’s consumer “Embed a map” → “Copy HTML” flow gives you an iframe that embeds a Google Maps view.

That matters because you’re not pulling review text into your site—you’re just hosting Google’s UI, with whatever review UI Google chooses to show inside that map.

Maps Embed API

The Maps Embed API usage and billing looks more “developer,” but it’s still an embed.

• Free to use, with unlimited requests
• No daily or usage rate limits
• API key required for every request
• Renders a Google-controlled map view
• Not a review-text API

Places API

Places API is a developer API that can return review data you render yourself. But the ceiling is built in: the Places API reviews[] field can return a maximum of 5 reviews, and they’re sorted by relevance.

If you show those reviews, you also inherit display obligations: credit the review author (including at least their avatar when space is tight), give end users direct access to the source review on Google Maps via the provided googleMapsUri, and show a clear notice explaining how you ordered and filtered the reviews (with “relevance” as the default ordering).

Business Profile API

If you need a fuller review list, the Google Business Profile APIs are the official route.

• Works only for verified locations
• Access is tied to the authenticated account
• Returns a paginated list of reviews
• Maximum pageSize is 50

Quick method matrix

Use this to decide what you can actually render before you pick a widget.

Places API: the ceiling

Any “Google reviews widget” backed by Place Details inherits Place Details’ hard review limits. The limit isn’t a UI decision—it’s baked into what Place Details will return, even before you design a carousel or grid.

Place Details (New)

In Place Details (New), the reviews[] field is relevance-sorted. The response can return a maximum of 5 reviews—per the Places API Place resource.

Place Details (Legacy)

In Place Details (Legacy), reviews is a JSON array of up to five reviews. By default, they’re sorted in order of relevance, and the reviews_sort request parameter can control sorting.

What this breaks

If your widget is backed by Place Details, it can’t behave like a true “review feed.”

• No “all reviews” feed from Places alone
• No infinite scroll from Places alone
• “Show everything” claims conflict with Place Details responses

If a tool shows a full history, it isn’t coming from Place Details alone.

Fields and billing

In Places API (New), reviews and reviewSummary are billed as Place Details “Enterprise + Atmosphere” fields/SKUs. That’s why “just grab reviews” is never a free add-on field—you’re explicitly opting into a billed data category.

Use a field mask (for example, X-Goog-FieldMask) so your Place Details request asks only for what you actually render.

Business Profile API: the workaround

If you need to display Google reviews on website beyond the Places “top 5,” the official route is the Google Business Profile API. The core call is a true list endpoint: accounts.locations.reviews.list (mybusiness.googleapis.com v4). It’s designed to fetch review history for locations your authenticated account manages—not to pull public reviews for any business you can name.

Ownership gate

You don’t get “any place’s reviews” here. You get your location’s reviews.

• The location must be verified under your account
• The request must be authorized for that specific location
• The call is scoped to the location resource you pass
• You can’t use it to list reviews for unowned locations

Endpoint behavior

accounts.locations.reviews.list is a list endpoint: it returns review resources for one location, plus pagination data so you can keep going. That’s the key difference versus Places’ fixed reviews[] field—you can build a real “all reviews” UI because you can keep requesting pages. If you’re implementing this end-to-end, see the ShowTrust API docs for a practical reference.

Paging constraints

These two parameters are how you turn the endpoint into an infinite scroll or “Load more” experience.

Sorting you control

Unlike Places’ relevance-sorted five, this endpoint lets you choose an order.

• updateTime desc (default)
• rating
• rating desc

When it’s worth it

Use the Business Profile API when you need more than five reviews and you control the listing you’re displaying. If you don’t manage the location, treat “full review history” promises as a red flag and stick to embeds—or accept Places’ five-review ceiling in your own UI.

Display rules you inherit

When you display Google reviews on website using review data (not an iframe), you’re responsible for reproducing parts of Google’s review UX. These aren’t “best practices.” They’re UI requirements that change what your components must render and where you must put it.

Author attribution

You need on-card credit that clearly identifies who wrote each review.

• Author avatar (minimum in tight UI)
• Author name
• A visible “Review by” attribution line

Mandatory source access

Each displayed review must offer direct access to its source on Google Maps.

In practice, that means a visible link or button per review (for example, “View on Google”) that deep-links to the review’s provided googleMapsUri, not just to your own “all reviews” page.

Ordering and filtering notice

If you do any curation at all, you must tell users what you did.

1. State the default order as “relevance.”
2. If you change ordering, disclose the new order (for example, rating or newest).
3. Disclose any filters or search criteria you apply.
4. Place that notice near the rendered reviews.

France visitDate rule

For places in France and French territories, the Places API returns a visitDate (the month and year the reviewer visited) and you must display it alongside the review content.

Treat it like part of the review body, not optional metadata you can hide in a tooltip.

Marketing reuse consent

There’s a separate rights issue that sits above UI compliance: Google’s guidance treats review text as belonging to the person who wrote it.

If you want to use a review “as marketing” (including on your website), you must get the reviewer’s consent—even if you can technically fetch and render the text.

What Google forbids

If you want to display google reviews on website, the biggest compliance risk is building a “reviews database” by copying content out of Google Maps. Google Maps Platform’s terms explicitly prohibit scraping Maps content, including copying and saving user reviews.

• Don’t scrape Google Maps pages to copy and save user reviews.
• Don’t store scraped review text, ratings, or author details in your database.
• Don’t extract reviews from embedded map HTML and republish them as a feed.
• Only temporarily cache Places latitude/longitude, then delete after 30 consecutive days.
• Treat any “review backup” workflow as prohibited Maps content scraping.

If your reviews keep working when Google is unreachable, you’ve probably stored something you shouldn’t.

Pricing after March 2025

As of March 1, 2025, Google Maps Platform removed the $200 monthly credit and replaced it with free monthly calls per SKU.

If you’re trying to display google reviews on website via an API, don’t “estimate cost” from old credit math—map your requests to the SKU first.

SEO: star snippet myth

Eligibility rule

Google’s review snippet guidelines draw a hard line: if the reviewed entity controls reviews about itself, the page isn’t eligible for star review features. In practice, that means pages using schema.org/LocalBusiness or schema.org/Organization markup don’t qualify for review stars when you’re marking up your own business.

Widget example included

Google also makes the “but we used a widget” argument non-starter.

• Ineligibility includes embedded third-party review widgets
• Review source doesn’t override the rule
• Example explicitly called out: Google Business reviews widget

Practical takeaway

Stop promising “display google reviews on website” as a shortcut to “get review stars in SERPs.” The common pitch is: embed third-party reviews, add review schema, and you’ll earn star snippets—but Google’s documented eligibility rule blocks that for self-controlled entities, including when the reviews are shown via an embedded widget.

Implementation playbook

Your implementation choices are constrained by the Google surface you’re using. Pick the compliant path first, then build the UI that path actually allows.

Embed without plugins

Use an embed when you want Google to host the review UI inside your page.

1. Use the consumer embed if you’re fine doing it manually, or choose the Maps Embed API if you need to generate embeds in code.
2. For the consumer route, open the place in Google Maps, click “Embed a map,” then “Copy HTML.”
3. For the Maps Embed API route, create and attach an API key to the embed URL.
4. Paste the iframe into your page where you want it to appear (see what an embed code is if you need a refresher).
5. Accept the tradeoff: you’re embedding Google’s UI, not rendering a controllable review feed.

Render Places reviews

Render Places reviews only when you can live with a small, fixed set and the required on-card disclosures.

1. Request Place Details with a field mask that includes reviews (and only what you render).
2. Render the returned reviews as-is, and never design a UI that implies “all reviews.”
3. Add per-review author credit in the card (name plus avatar when space is tight).
4. Add a per-review “View on Google” deep link using the provided googleMapsUri.
5. If you expose a “Report” affordance, wire it to the provided flagContentUri, not your own moderation flow.

If you’d rather not hand-roll markup, the Places UI Kit Place Details Elements can render reviews for a selected place.

Render Profile reviews

Use the Business Profile API when you need a true, paginated review list for a location you manage.

1. Confirm the location is verified under the Google account that will authorize API access.
2. Call accounts.locations.reviews.list for the specific location resource.
3. Paginate with pageToken, and keep pageSize at or below 50.
4. Apply only the allowed sort options (default updateTime desc, plus rating and rating desc).
5. Render each card with clear provenance (a visible “Google” source label) so users know what they’re viewing.

Storage boundaries

Don’t turn Google reviews into your database. Google Maps Platform’s “No Scraping” restriction explicitly includes “copy and save” user reviews, so storing review text (or rebuilding a feed from saved reviews) crosses the line.

If you store any Maps Platform latitude/longitude, the service-specific terms only allow temporary caching for up to 30 consecutive calendar days, after which you must delete it.

If you need permissioned quotes you can keep and curate, ShowTrust lets you collect testimonials directly and publish a “wall of love” widget while still linking out to Google as the verification source.

Disclosure microcopy

If you filter or curate, users must be able to see what you did. “We only show 5-star reviews” isn’t a design detail if you’re rendering Places data; it’s something you have to disclose.

• Ordered by: relevance (default)
• Ordered by: newest (updateTime desc)
• Filtered by: rating ≥ 4
• Filtered by: keyword “delivery”

Choose the source first, then design around its limits

Most “Google reviews widget” advice falls apart because it starts with the UI instead of the source. If your plan depends on displaying a full, dynamic feed, stop and validate the ceiling first: the Places API reviews[] output is sorted by relevance and returns a maximum of 5 reviews. Once you pick the surface you’re using, treat every requirement it inherits—links back to the source, attribution, ordering/filtering disclosure, and storage boundaries—as part of the implementation, not optional polish.