Where to place it, how to embed without wrecking page speed, and the accessibility and SEO details most implementations miss.
Embedding a tour is technically a two-minute job and a frequently botched one. The iframe is easy; not destroying your page speed, and making the page still mean something to search engines, is where it goes wrong.
Where to put it
Above the fold on the relevant page, or immediately below a short intro. Buried at the bottom of a long page, a tour gets almost no engagement — and it is usually the heaviest asset on the page, so you are paying its cost without the benefit.
For a multi-location business, the tour belongs on that location's page, not a single "virtual tour" page listing them all. See multi-location local SEO.
Do not let it load on page load
This is the important part. A tour viewer typically pulls several megabytes of JavaScript and imagery. Loaded eagerly, it will dominate your Core Web Vitals and slow the whole page for every visitor, including the majority who never interact with it.
Use a facade: show a still image with a play button, and load the real embed only when someone clicks. Two attributes get you most of the way even without one:
loading="lazy"on the iframe, so it does not load until it is near the viewport- Explicit
widthandheightor an aspect-ratio wrapper, so the page does not jump when it arrives
Make it responsive properly
Wrap the iframe in a container with a fixed aspect ratio rather than setting a pixel height. A 16:9 or 4:3 wrapper keeps the tour usable from a phone to a widescreen monitor without letterboxing or clipping.
On phones, give it a real height — around 60% of viewport height works well. A tour squeezed into 200 pixels is unusable, and people will not pinch-zoom to fix it.
Test on a mid-range phone on mobile data. Tour viewers are heavy. If it takes fifteen seconds on a normal connection, most visitors will never see it — and you will not discover that on office wifi.
The accessibility and SEO details
An iframe is opaque to search engines and to screen readers. The page needs to convey the same information in text:
- Give the iframe a descriptive
titleattribute — "360° tour of the Manchester showroom", not "tour" - Write a real text description of the space near the embed. This is what actually ranks; the iframe does not.
- Provide a fallback link to the tour's own URL, so it works if the embed fails
- Ensure the play button on your facade is a real
<button>, reachable by keyboard
Measure engagement
Fire an analytics event when someone activates the tour, and if the viewer supports it, track scene changes. "Did people open it" and "did they explore past the first scene" are two different and both useful questions — and they tell you whether the tour is earning its place on the page.
Frequently asked questions
Does embedding a virtual tour slow down my website?
It will if you embed it eagerly — viewers are often several megabytes. Use a click-to-load facade or at minimum lazy loading, and the cost falls only on visitors who actually want it.
Can I embed a virtual tour on Wix, Squarespace or WordPress?
Yes, all support iframe embeds via an embed or custom-HTML block. The lazy-loading and aspect-ratio advice applies equally — platform embed widgets often load eagerly by default.
Will an embedded tour help the page rank?
Not directly — search engines cannot read inside the iframe. It helps indirectly by increasing time on page and engagement. The ranking still comes from the text on the page around it.
