Share a Google booking page: link, popup button or inline embed
A direct booking link, a website button and an inline booking page can lead visitors into the same scheduling service through different presentations. Choose the destination first: one specific service or all booking pages on the primary calendar. Then inspect what a public visitor will see.
A fictional repair business’s distribution map
| Location | Intended destination | Visitor check |
|---|---|---|
| Setup product page | One setup consultation | No unrelated service choices |
| General contact page | All intended booking pages | Expected service list and identity |
| Email message | Direct booking link | Correct destination without embedded code |
Start from the visitor’s next decision
For a fictional repair business, a product page should offer only its setup consultation, while a general contact page may list all services. Record page location, intended service scope and button wording before copying code. A button labelled Book a setup call should not unexpectedly expose unrelated offerings.
Google says a booking page is public and its profile photo and account name are visible to anyone with the link. Hiding the calendar from your own list does not make that page private. Review the public identity before adding the URL to an email signature or website.
Choose the supported delivery format
On a computer, Google documents hovering over the intended page under Booking pages, then choosing Options > Sharing options > Website embed. Choose All booking pages or A single booking page, then Button with popup or Inline booking page. Copy code, click Done and paste the generated code into the website’s HTML.
Use a direct link where the channel does not support embedded code. For a website, decide whether visitors should open a popup or see the form within the page. The source describes button text/color choices and inline width/height adjustments, but it does not establish that every host permits every script or embed.
Review a small publishing checklist
For the repair example, compare the specific-service destination with the all-services destination before publication. Inspect the displayed business identity, service description, currently offered slots and the page’s behavior on the website layout you actually use.
Use one cooperative colleague to follow the visitor route. Ask them to report where they arrived rather than saying the button works because it changed color. If you agree a test booking, check its confirmation and remove it through the normal supported route. Do not use a customer’s real appointment as a layout experiment.
Maintain the distribution map
Keep a private list of published locations: product page, contact page, signature and campaign message. If the intended service or booking destination changes, revisit those locations instead of assuming every previously copied URL has been updated.
This is Google’s booking-page publication workflow. It differs from embedding a public calendar grid, sending an agreed meeting invitation, or sharing an editable calendar. Cloud Calendars views do not by themselves create these booking-page controls.
What it looks like
Cloud Calendars overview, using our product images. Provider settings and protocol examples described in this guide are separate from the screens shown here.
What to do
- Choose one service or the intended all-services page.
- Review the public account identity.
- Use a link or the supported website embed option.
- Check the real visitor destination and record every published location.
Questions
- Does hiding my calendar hide the booking page?
- Google explicitly says calendar-list visibility does not control the booking page’s public visibility.
- Is embedding a calendar the same as embedding a booking page?
- No. One displays schedule information; the other asks a visitor to choose an appointment. Use the code and destination for the intended task.