Google Does Not Read Your Embedded Widget: The Services Search Never Sees

You have probably been told that if something appears on your page, Google can read it. For ordinary text, that holds. Inside the box where your customers pick an appointment slot, choose a table or scroll a price list, it frequently does not, and nothing on your screen tells you which situation you are in.

That box is an embed. Somebody set it up for you, or a plugin did, and it works. Customers book. Orders arrive. The page looks finished. Underneath, the words that would win you a search result may be sitting on another company's domain, wrapped in instructions telling Google to leave them alone.

This is an operational guide to working out which kind you have and what to do about it. The check takes about fifteen minutes and needs no specialist.

An embed is a window, not a page

Two different things get called embeds, and the distinction decides everything that follows.

The first is a script. A vendor gives you a few lines of JavaScript, your page loads them, and the script writes its content directly into your page. Google's JavaScript SEO documentation describes what happens next: pages returning a 200 status get queued for rendering, and once Google's resources allow, a headless Chromium renders the page and executes the JavaScript. Content written into your page this way is usually indexable, because by the time Google files the page, the words are in it.

The second is an iframe, and an iframe is not content on your page at all. It is a window cut into your page, displaying a separate document served from the vendor's own address. Your visitor cannot tell the difference. Google can.

What does that mean for the owner? If your treatments, durations and prices live inside an iframe, they may be filed by Google as somebody else's content at somebody else's address. Your page gets credit for a heading and a button.

Google's own answer is "not guaranteed"

Asked directly whether the contents of an iframe are associated with the page doing the embedding, John Mueller answered in Google's December 2023 SEO Office Hours that Google's systems "would try to associate the sub-page's content as a part of the primary page for indexing, but it's not guaranteed, since both pages are normal HTML pages on their own too" ^[1].

Read that twice, because it is as good as the guidance gets. That is not a rule, and it is not a promise. It is an attempt, made on a document Google also treats as independent.

I would not run a sales channel on "not guaranteed", and neither would you if the alternative were visible. Which is the whole problem. There is no error here, no warning in a dashboard, no drop in traffic to investigate. The enquiries simply never arrive, and nothing in your reporting explains why.

The noindex trap most widget pages carry

Now for the part almost nobody checks.

Widget vendors generally do not want their bare widget endpoints ranking in Google as pages in their own right. An unbranded booking form is not a search result anyone wants. So those endpoints commonly carry a noindex tag, which is sensible housekeeping on the vendor's side.

Google spelled out the consequence when it introduced the indexifembedded tag on 21 January 2022. Writing on the Search Central blog, Weizi Wang and Gary Illyes explained that publishers using noindex on media pages ran into a problem, because "the noindex tag also prevents embedding the content in other pages during indexing" ^[2]. The new tag exists precisely to permit indexing when a noindex page is embedded through an iframe. Two details matter to you. It has to be added by the vendor, on the vendor's page, not by you. And Google's post states plainly that only Google supports it, so every other search engine ignores it entirely.

The practical upshot is hard-edged. If your service list sits inside an iframe whose source page carries noindex without indexifembedded, that content will not be indexed as part of your page. Not slowly, not partially. You cannot fix it from your side, you cannot see it from the front end, and Google's JavaScript documentation notes that a robots tag telling Google not to index a page keeps it out of the rendering queue in the first place.

The second trap: content behind a click

Suppose your widget is a script rather than an iframe, so rendering happens on your own page. There is still a way to hide your prices from search, and it is a common one.

Google's mobile-first indexing guidance is blunt about it: "Don't lazy-load primary content upon user interaction. Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load" ^[3]. The lazy-loading documentation reduces the principle to a single sentence: "Google Search does not interact with your page" ^[4].

Think how many service pages are built that way. Tabs that fetch their content when clicked. An accordion pulling prices from an API when opened. A "see full menu" button that loads the menu after the tap. Or a location dropdown that loads that branch's services on selection. In every one of those cases a human sees everything and Googlebot sees the first state only.

Street level: if a customer has to tap before your prices appear, Google never tapped, so your prices were never indexed, so the search that would have found them went to a competitor who wrote theirs in plain text.

Where this quietly costs the enquiry

Consider a pattern we see often rather than a specific business. A sports-massage therapist in Westmeath runs her entire diary through an embedded booking system. Treatment names, durations, prices, the Saturday morning slots she deliberately keeps open for club injuries: all of it inside the box. Her treatments page, as Google holds it, is a heading, two lines of introduction and a button.

Somebody pulls a hamstring at training on a Tuesday evening and searches for sports massage near them with a weekend appointment. Two clinics come back. Neither is hers. She has the availability, she has the pricing, she has the weekend cover, and none of it exists in a form the search engine could use.

She will never see that loss. No visit to explain, no abandoned form, no bounce to investigate. The decision happened somewhere she has no visibility at all, on words she never published.

This is not a rare setup. The Central Statistics Office reported that in 2025 around 29% of enterprises had online ordering, reservation or booking on their website, while roughly two thirds published information about goods, services or prices ^[5]. Booking facilities are common. Whether the wording around them is readable is a different question, and nobody audits it.

Which businesses have the most content locked in a box

• Appointment-led services. Physiotherapists, groomers, driving instructors and garages tend to keep their whole service and price list inside the diary tool. The searches they lose are the highest-intent ones, where somebody wanted a named service at a named time.
• Food businesses. A menu delivered through a third-party ordering platform takes every dish name out of your own HTML. Somebody searching for a specific dish in your town finds the platform, if anyone, and you pay commission on an order that started as your search result.
• Retailers running a supplier catalogue feed. Product names and specifications arrive inside a vendor frame, so the category page you hoped would rank has no product text of its own to rank with.

How to verify what Google actually has, in four steps

• Inspect. Open Google Search Console, run the page through the URL Inspection tool, then use "View crawled page" to read the HTML Google stored. This needs a verified property for your domain, which is free to set up.
• Compare. Search that stored HTML for a treatment name, a dish or a price you can see in your browser. Anything absent is content Google does not hold for your page.
• Duplicate. Write the missing names, descriptions and prices into the page itself as ordinary text, above or below the widget, and deploy the change.
• Verify. Re-inspect the URL a few days later and confirm the words now appear in the crawled version, not just on screen.

A word on that first step, from getting it wrong ourselves. For a long time our pre-launch checklist confirmed that pages rendered correctly in a browser. Rendering correctly and being indexable are different properties, and we learned the difference on a client site whose service pages looked flawless on screen and were close to empty in the index. The checklist asks for the crawled version now.

What a page built for this looks like

Leave platform names aside and describe the standard any decent setup should meet.

The words that earn the ranking belong in your own HTML, on your own domain, in production, where you can edit them. A widget should handle the transaction and nothing else: taking the booking, holding the slot, processing the payment. Prices and service names should also appear in machine-readable form, which is the same discipline covered in our guide to structured data on small business pages. And the owner must be able to make the change without raising a request with anybody, because a page you cannot edit yourself is a page that stays wrong.

There is a performance dividend too. Third-party embeds are the heaviest thing on most business pages, and the Web Almanac's 2025 analysis of the HTTP Archive crawl found that 90% or more of pages load at least one third party ^[6]. Publishing your own text instead of loading another frame to display it is one of the few changes that helps both indexing and load time, which is the thread running through our complete WordPress performance guide.

That last criterion, the one about editing it yourself, is where rented platforms fail most often. WordPress does not, and that is the practical reason the fix is available to an owner at all: you open the editor, add a real section with real text, and deploy. It is the whole point of running a full WordPress site you control and can edit yourself for €60 a year, on Irish infrastructure, rather than renting a page somebody else assembles for you.

The honest limits of this fix

Three, and they matter.

Duplicating your service list onto the page creates two places to update. Change a price in the booking system and the page text is wrong until you change it too, and a wrong price on a public page is a considerably worse problem than an unindexed one. Agree a review interval and hold to it.

Live availability genuinely cannot be indexed, and it should not be. A search result offering a Saturday 10am slot that went days ago costs more trust than it wins. Index what is stable: services, durations, prices, areas covered. Leave the diary to the widget.

And this is a fix to eligibility, not to position. Making your services readable puts you in the running for searches you were absent from. Google still decides the ranking, and a stronger competitor may simply be better placed on the day.

One genuine exception, because it comes up on calls. A business whose bookings all arrive through a single hospitality or appointments platform, whose own listing pages rank well, and whose owner has no intention of building an organic channel, is not wasting money by leaving the content in the widget. The platform's own search visibility is doing that work, and for some operators that is the right trade. It stops being the right trade the day you want enquiries that do not carry a commission.

Conclusion

Everything inside the widget belongs to the transaction. What a customer would type into a search box belongs to you, published in your own page, in words you control and can change on a Tuesday afternoon without asking permission.

Spend fifteen minutes with the crawled version of your busiest service page and you will know which side of that line your business currently sits on. Then you can decide what to move across.

Frequently Asked Questions

Does Google index content inside an iframe?

Sometimes, and Google will not promise more than that. Asked the question directly in its December 2023 SEO Office Hours, Google said its systems would try to associate the embedded sub-page's content with the primary page for indexing, but that this is not guaranteed, because both pages are normal HTML pages in their own right. If the embedded page also carries a noindex tag without the indexifembedded tag, its content is not indexed as part of your page at all.

Why are my prices not showing in Google when they are on my page?

Usually because they are not on your page in the way Google reads pages. If the prices sit inside a booking or menu widget delivered as an iframe, they belong to a separate document on the vendor's domain. Where they load only after a visitor clicks a tab or a "see more" button, Google never clicks, so it never loads them. Google's own guidance states that it will not load content requiring user interactions such as swiping, clicking or typing. Check the crawled HTML rather than the browser view to see which case applies to you.

Are embedded widgets bad for SEO?

No, but keeping your only copy of important text inside one is. A widget handling bookings, payments or availability is doing a job no search engine needs to read. The problem arises when your service names, descriptions and prices exist nowhere except inside the widget, because those are exactly the words a customer types into Google. Run the transaction in the widget and publish the wording as ordinary text on your own page.

How do I see what Google actually reads on my page?

Use the URL Inspection tool in Google Search Console, run your page through it, then open "View crawled page" to read the HTML Google stored. Search that stored HTML for a treatment name, dish or price you can see in your browser. Anything missing is content Google does not hold for your page. You need a verified Search Console property for the domain, which is free to set up.

Should I remove my booking widget to improve my rankings?

No. Removing a working booking channel to chase a ranking trades revenue you already have for traffic you might get. The fix is additive: leave the widget doing the transaction and write the service names, durations and prices into the page as text, ideally with structured data alongside them. One caveat worth knowing: this creates two places to update, so agree a review interval and keep the published prices accurate.

Sources