by Graham Dyer Open almost any new apartment website and look at how it shows its homes. There is a good chance you will find two tabs. One says something like ‘Interactive Map’ and holds a beautiful Engrain SightMap® with live availability and all-in pricing. The other says ‘Floor Plans’ and holds a grid of static picture cards. They sit side by side, look like two halves of one tool and barely know each other exists. We call it the two-tab problem.
The pattern is so common it reads as the normal way to build an apartment page. It is also the reason a renter who has already picked out a home can end up hunting for it a second time, and the reason none of your current rents appear in your own page’s text, where Google and an AI assistant would read them.
The map tab and the floor-plans tab
The first tab is the good one. On a live SightMap you pan the building, click a unit to see its price and its move-in date, filter by bedrooms or budget. It has the polish Engrain is known for, and on most sites it is the strongest leasing tool on the page.
The second tab is where the drop happens. Labeled ‘Floor Plans,’ it is a grid of static image cards: a picture of each layout, a name, maybe a bed-and-bath count and an ‘Availability’ button. It carries no live price, no move-in date and no way to act on a specific home. A renter who lands here after the map feels the difference immediately, as if the site went dark.
Why it happens, and why it is nobody’s fault
The two tabs are two different systems. The SightMap is served from Engrain’s domain inside an iframe (a sealed window in your page), and the floor-plans tab is built separately, as ordinary content in your website’s CMS. Two sources of data, no shared state and a page that cannot read the content inside the frame. Nothing wires the two together on its own.
Given that, the two-tab build is the reasonable path. A studio doing beautiful design work is rarely staffed to wire live data between a sealed frame and a hand-built page. So the map gets embedded, the cards get built by hand and the site that launches photographs well although nothing runs between its two halves. The gap only becomes visible once renters, and crawlers, start arriving.
What it costs in leases and in search
The disconnect is invisible on a demo call. It shows up once prospects are on the page, and the first place is the filters. Two-tab sites often carry two separate sets of controls: the page’s own filter bar (bedrooms, price, square feet) sitting above the map, and the map’s own filtering sealed inside the frame. Set the outer one and nothing happens to the map below it, because nothing wires that outer bar to the sealed map; connecting them takes Engrain’s IFrame API and custom JavaScript, exactly the build the two-tab pattern skips. Filter the map, meanwhile, and the static floor-plans tab does not follow.
The floor-plans tab is where a renter goes next, and its cards are pictures rather than data. The ‘Availability’ button does not open that home. At best it bounces the visitor back to the map to start the search over, and the layout they were looking at carries none of the current price or move-in information that would help them decide.
Say a renter does find the exact unit they want anyway. The static card gives them no direct way to apply for that one. Clicking through hands them to the leasing system (Yardi RentCafe, AppFolio, whichever PMS the property runs) at its front door, where they begin again: choose the community, filter to the bedroom count, hunt down the unit they had already picked. Most modern leasing systems can accept a link that carries the specific home, or at least its floor plan, into the application. The flat two-tab card never carries one. So a prospect who was ready to apply is asked to find their apartment a second time, and some of them stop there.
Search has the same trouble, for the same reason. Everything live sits inside the frame, and content in an iframe belongs to the frame’s domain, not your page. When Google crawls your floor-plans page it finds the static cards and little else. Ask ChatGPT or Claude for ‘two-bedrooms under $2,400 near downtown’ and the model cannot lift a single fact about your inventory, because as far as it can read, the facts are not there. Our AI-visibility playbook goes through what a crawler and an assistant can read on a property page, and what to do about the rest.
Three checks on your own site
Open your own property page and run these:
- Filter, then switch. Filter for a two-bedroom on one tab, then switch to the other. Do the results carry over, or does the second tab ignore you entirely?
- Pick a unit, then apply. Find a specific home you like, then try to apply for exactly that one. Does a link carry it into the application, or are you dropped at the leasing system’s front door to start over?
- View the source. On your floor-plans page, open the browser’s ‘View source’ and search for a current price or a move-in date. If the live numbers are not in the page’s own HTML, neither Google nor an AI assistant can read them either.
If any of those falls flat, you have the two-tab problem, and plenty of company.
A tooling answer to a storytelling question
The labels themselves give the game away. ‘Floor Plans’ and ‘Interactive Map’ are two tools, two ways to look at the same list, as though choosing a home were a matter of picking a viewer. But nobody falls for an apartment because they toggled to the map view. They fall for the light in the corner unit, the courtyard they would cross every morning, the neighborhood they want to belong to. A leasing page is meant to tell that story and let the map and the homes live inside it. Dropped into a frame that speaks to nothing around it, the map is cut off from the photography and the amenities that would do the telling.
The native integration
The way out is one page whose surfaces all read from the same feed. Keep the SightMap where it belongs. It stays the interactive centerpiece, and what surrounds it—the floor-plan cards, the unit list, the rents and the move-in dates—renders as HTML on your own domain, drawn from the data that feeds the map.
One set of filters then drives both. Because there is only one list to filter, a renter who narrows to two-bedrooms under $2,400 keeps that shortlist whichever way they are looking at it. Underneath sits the structured data that lets a search engine or an AI assistant read every unit. Tour scheduling feeds your own lead capture. And because it is one page rather than two tabs, the map can sit inside the property’s story instead of waiting on a tab beside it.
Historically that was a custom development project. We built WP FloorMap to remove it. On every plan it generates your entire multifamily website from your SightMap and PMS data and Foreword sets it up for you, live in an afternoon. It costs less per month than a typical agency retainer. Already have a WordPress site you’d like to keep? We can integrate WP FloorMap into it. Talk to us. If you want the full walk-through of the embed and the native approach side by side, start with how to embed Engrain SightMap on your website.
Frequently asked questions
What is the two-tab problem on an apartment website?
It is a common apartment-website layout where the interactive map lives on one tab and a grid of static floor-plan cards lives on another, and the two never share data. The map tab is live and current; the floor-plans tab is a set of pictures with a name and a bed-and-bath count. Because the map is embedded as a sealed iframe and the cards are built separately in the site’s CMS, filtering one does nothing to the other, and the live availability and pricing stay locked inside the frame.
Why don’t the map and the floor plans on my apartment site match?
Because they are two different systems with two different data sources. The SightMap is served from Engrain’s domain inside an iframe, and the floor-plans tab is hand-built content in your website’s CMS. A page cannot read the content inside a cross-origin iframe, and nothing wires the two together on its own, so there is no shared state: filter the map and the cards do not follow, update a price in your PMS and the static card keeps the old number. Matching them requires pulling the same live data into both surfaces, which is exactly what a native integration does.
Do static floor-plan cards hurt my SEO?
The live units inside an embedded map are invisible to search engines and AI assistants, because content in an iframe belongs to the frame’s domain, not your page. That leaves the static floor-plan cards as the only thing crawlers can read on your floor-plans page, and a picture with a label carries no availability, no price and no structured data. The fix is to carry the same unit facts on your own page, in its own HTML and structured data, so the map is for people and the text layer is for machines.
How do I connect the SightMap to my floor-plan cards?
You give both surfaces one source of truth. A native integration renders live floor-plan and unit cards from the same data that feeds the map, so one set of filters drives the map and the list together and structured data sits underneath for search and AI. On WordPress, WP FloorMap does this for you: on every plan Foreword builds the whole site, and we can integrate WP FloorMap into a WordPress site you already run.
One page, one set of filters, one source for the numbers. The demo sites are built that way, and every unit on them is text a crawler can read rather than pixels inside a frame. Send us a SightMap link and we will show you the same thing with your own inventory.
