Why project pages often go unfound
The typical developer site is built like a presentation. A huge render on the first screen, a two-line tagline, a "request a call" button. For someone who already knows the project, that is enough. For search it is almost nothing: no district name, no address, none of the words a buyer uses to describe what they want.
A buyer does not search for a render. They search for a district, a neighbourhood, a development they heard about from a friend. For the page to answer, it needs text that answers.
One address per project
The first decision: every project gets its own page with its own URL. Not an anchor on the developer's homepage and not a tab inside one screen, but an address you can open, bookmark and send in a message.
The reason is simple. A search engine judges the page as a whole. If five projects share it, it answers five queries and none of them well. If it holds one project, the topic is clear. The developer's main site stays a catalogue that leads to each project page.
Name and location in the heading
The page heading should hold what people search with: the project name and its place. Not "A new life by the sea" but the actual name and district. The tagline can sit next to it; it should not replace it.
The same goes for the address. If the street or block is known, write it as text near the top, not only on a map. A map is an embedded widget, and a crawler reads it less reliably than a plain line of text.
Write about the neighbourhood, not only the building
This is where pages are usually empty. They are filled with facades and interiors, and nothing is said about what surrounds the building. Yet buying an apartment is mostly a decision about a place: how far from work, where the school is, where the shop is, how you get around.
What to put in plain copy:
- how to get there: transport, main roads, travel time to well-known landmarks;
- what is nearby: schools, shops, parks, clinics, by name, only what actually exists;
- what the area looks like today and what will change, if documents support it;
- who the project suits, and why.
All of it has to be true and checkable. "Developed infrastructure" answers no question and gives a search engine nothing to hold onto.
Floor plans as text
Plans are usually shown as images or an interactive picker. That is good for a person and poor for search, because the picker's content is often built in the browser and never reaches the crawler. We wrote about the design side of choosing a unit in apartment selection UX and interactive floor plans.
The practical fix is not to drop the interactive part but to repeat the essentials as text or a table: unit type, area, floor, status. The page then works for a person with a mouse and for a robot that reads only HTML.
Structured data
Once the copy is in place, repeat it as markup. On a project page that means the object's name and address, the developer, and a block of questions and answers. Markup does not replace copy and does not promise rankings, but it removes guesswork about what the object is, who builds it and where it is. How JSON-LD works is covered in structured data explained.
One rule: markup holds only what is on the page. If the address is not in the copy, it should not be in the code either.
Six checks for your project page
- Does the project have its own URL, not an anchor on a shared page?
- Are the project name and district in the heading?
- Is the address written as text, not only shown on a map?
- Is there a section on the area that names real places around it?
- Do the plans read without scripts? Open the page with JavaScript off and look.
- Do the text and the markup say the same thing?
These take an hour. They promise no particular position in results, but without them it is harder for a search engine to understand what the page is about. For the wider picture of what a project site needs, see off-plan project website: what buyers need to see, or what we build for developers.
