Real estate listings on your agency website and on portals: duplicates, outdated ads and inquiries

Why publish listings on your own site, even though clients search on portals

A real estate portal is a convenient tool for the client — one search, hundreds of results. But from the agency's perspective, it has limitations. First, the portal mediates the contact — the client writes through the portal's form, and you only see them when the portal forwards the inquiry (sometimes with a delay, sometimes not at all). Second, on the portal your listing is one of thousands — it competes for attention with competitors, and the presentation format is set by the portal's rules. Third, you don't build your own visibility in Google — clients who search "apartments Mokotów" or "real estate agency Warsaw Ursynów" will find portals, not your site.

Your own site provides three things the portal cannot. First, full control over presentation — you can show the complete object history, additional materials, comparisons with similar apartments in the area. Second, direct inquiries — the client contacts you directly, not through an intermediary, and in the process sees your contact details and logo. Third, visibility in Google for local queries — when someone searches "apartments for sale Ursynów" or "apartments Wilanów," your site can appear alongside the portal if it's optimized.

Your own site doesn't replace the portal — it complements it. A client who lands on the portal can click your profile and go to the site with the full listing. Or vice versa — someone finds you in Google and goes to the portal to see more listings. Both paths are valuable, but for them to work, you need to ensure data consistency across channels.

What you can show on your own site that you can't on a portal

On a portal, you must fit into rigid constraints — main photo, a few extras, price, area, location. On your own site, you can go further. You can show a full photo gallery and video walkthroughs. You can add a floor plan, a neighborhood map with service points (schools, kindergartens, shops), comparisons with other apartments in the building or estate. You can show price history — how much the apartment cost a year ago, how much now, what influenced the change. This builds trust and demonstrates professionalism.

You can also build location-specific pages — "apartments in Mokotów," "houses in Wilanów" — and aggregate listings from that area. This gives better visibility in Google for neighborhood-related queries, because the site becomes a local information hub. Portals don't allow this level of customization.

One source of truth: how to organize data flow between CRM, site, and portals

The biggest problem with managing listings appears when the same object is edited in many places independently. You change the price in CRM but forget to update it on the site. You add a new photo on the portal but the old one remains on your site. Then clients who encounter different channels see different data — and lose trust.

The solution is one: a single source of truth. The object is created in CRM, from there it's automatically distributed to the site and all portals. When you change the price, status, or description — you change it in one place, and the system propagates it everywhere.

After-hours scenario:

This isn't complex logic — some modern CRM systems for real estate agencies have built-in integrations with popular portals. If your system doesn't offer this, you can build an integration via API (checking what the portal exposes) or use middleware tools that synchronize data between systems. The key is establishing which data is the source of truth and which is just a copy — and sticking to this principle consistently.

What breaks when you copy manually

When you enter data manually in multiple places, errors appear that cost you clients. The most common problems are price discrepancies — an illustrative example with assumed figures: the client sees 650,000 PLN on the portal but 670,000 PLN on your site, and doesn't know which information is current. The second problem is outdated photos — the same apartment, but on one channel there's a photo with renovation in progress, and on the other it's already after renovation. The third problem is status discrepancies — the apartment is already sold, but it still appears as available on your site because you forgot to remove it. The fourth problem is duplicates — the same object appears under multiple URLs because someone created a copy "just in case."

Each of these errors is a potential client who loses trust or goes to the competitor. Automating data flow eliminates these risks — but requires one-time setup and establishing rules.

Duplicates on your own site: where they come from and how to fix them

The most common cause of duplicates is filters and sorting that generate separate URLs for the same content. When a client views listings with filters "2 rooms, Mokotów" and "Mokotów, 2 rooms," they might land on two different pages with the same content. Similarly with sorting — "sort by cheapest" and "sort by most expensive" are different addresses, but the same list of objects.

Another cause is manually creating copies of listings for individual agents. Each agent in the agency wants "their own" listings on the site, so the same property appears multiple times, with different agents as contact persons. This is convenient for agents but costs visibility in Google — the search engine doesn't know which version to show and may lower the position of both.

If you don't have time to manually manage canonical addresses and Google visibility, that's what the SEO and maps service is for. Google's SEO guide explains that the same content under different addresses is duplicate content. This isn't a policy violation, but it can hurt user experience and waste crawl budget on addresses that don't matter anyway — and if you don't specify a canonical address yourself, Google will try to pick one automatically. For duplicate or very similar pages, you can indicate your preferred address to Google in several ways, including the <link rel="canonical"> element in the page's <head>. For property listings in a real estate agency, this means each property should have one canonical URL, and all variants (filters, sorting, agent copies) should point to this one address as the preferred version.

How to find duplicates on your site

Start by exporting the list of all URLs from your site. You can do this via sitemap.xml or using a tool like Screaming Frog. Then compare addresses for similar patterns — for example, all addresses containing the same property ID but with different parameters. Also look for duplicates of physical addresses — the same street and number in different variants (with Polish characters and without, with abbreviation and full street name).

Once you've identified duplicates, you have several methods to choose from, of varying strength. The strongest is setting rel="canonical" on the main version and redirecting the others. Second, remove unnecessary variants and keep one version. Third, weaker option — include only the canonical version in your sitemap: that's an additional, weaker signal that supports Google's choice but doesn't force it. Blocking variants in robots.txt won't help here — that's not a canonicalization tool, and Google may still index a blocked address without its content. Each situation is different — choose the approach that makes the most sense for your site's specific structure.

Sold or removed property: what to do with the page that's no longer current

This is one of the most common problems for real estate agencies. An apartment gets sold, but the listing page remains — sometimes with a "sold" note, sometimes with no information at all. The client clicks, sees old photos and price, wastes time, and leaves with a negative impression. Or even worse — the page looks active but no one answers the phone because the unit is no longer available.

You have three main options for handling sold properties. First, leave the page with clear "sold" information and recommendations for similar available apartments. Second, redirect (301) to the page with available listings in the same location or to the sales department page. Third, completely remove the page if it no longer has any informational value.

Watch out for soft 404 errors

If you leave an empty page with just the message "offer no longer active" and code 200 (the page displays, but has no content and no links), Google may treat this as a soft 404 error. This happens when a page returns a 200 status code but the content indicates an error — an empty page or just an error message. In this case, Search Console will show a soft 404 error, and the page may not get indexed at all.

The risk is specifically about an empty page with no content — not a page with "sold" information and real links to similar, available properties (see the table below): that page has content and value for the user, so soft 404 doesn't apply to it. It's worse when a page shows only an error message with no further content — then it's better to redirect it to active content (similar listings, sales department page), return a 410 (Gone) status code, or simply remove the page and update the sitemap.

Table: what to do depending on the situation

Publication date and freshness: how to show the client that the listing is current

A client searching for an apartment wants to know if the listing is current. If they see a publication date from March and it's now September, they'll probably assume something is wrong. On the other hand, a date from a few days ago means the unit is fresh and worth calling about.

Schema.org provides a special type for real estate listings — RealEstateListing. One of its properties is datePosted, which represents the date the listing was published online. That's a description of the data for search engines and other systems that read it — simply adding this property to the page code (via JSON-LD) doesn't guarantee any special display in search results. The real "freshness" of a listing is what the client sees on the page itself — the publication date and the last-updated date you put there.

Besides datePosted, it's also worth showing the last update date — if you changed the price or status, the date should reflect that. This builds trust and shows that the agency actively manages its inventory. You can also add visual freshness indicators — for example, a "NEW" badge for listings from the last 7 days.

Regular status verification

Even if you have automatic synchronization with CRM, it's worth doing a manual verification from time to time (once a month or quarter). Check if statuses on your site and portals match reality. Are all properties marked as "sold" actually unavailable? Do prices match? Are there any objects older than X months that still appear as active?

This verification can be part of your listing review cycle — for example, do it on the first day of each month. Set an automatic reminder in CRM, then simply review the list.

The property card that generates inquiries: what must be included

A client who lands on a specific apartment's page has one goal — quickly assess whether this unit is for them. If they have to scroll, hunt for information, call for details — they lose patience. The page should answer the most important questions in the first seconds.

What must be visible immediately: main photo (best, most representative), price (clearly, no hiding), area and number of rooms, location (district, street), floor and building condition. That's the minimum. Below — a short description of key advantages (what makes the unit special, what's included in the price, what requires extra payment).

Then you need clearly visible agent details — name and surname, photo (builds trust), phone number (clickable on mobile), email. Don't hide contact behind a form — give the option to call immediately. The contact form should be present, but not as the only option.

Contact form on the property card

A form is added value — it allows asking for details without calling, leaves a number that the system records in CRM. Important is that the form is contextual — the client asks about this specific apartment, so the form should include a hidden field with the listing number, so you know which property they mean. This way the inquiry goes to the right agent with full context.

You don't have to build a form from scratch — Aura offers a Lead forms service: interactive multi-step forms with conditional logic, where the next question depends on the previous answer, so nobody reads fields that don't apply to them.

For comparison, 41 of the 155 opened sites had no clickable phone number. A client who landed on such a page couldn't leave an inquiry directly — they had to find a phone number, call, or simply close the page and move on. We cover why clients abandon an inquiry in more detail in why customers don't leave inquiries.

Where inquiries come from: measure the source to know what works

If you run advertising campaigns, publish on portals, and have your own site — how do you know which channel brings the most inquiries? The answer is simple: you must tag each inquiry by source. When a client contacts you through the form on your site — that's source "own website." When they contact through a portal — that's source "portal" (Otodom, OLX, Morizon). When they call from Google Maps — that's source "Google Business Profile."

In CRM, you need a field that captures the inquiry source. For each new lead, you record where it came from. Then you can filter and analyze: how many inquiries from your own site, how many from portals, how many from ads, how many from referrals. Without this, you're working blind — you might be spending budget on a channel that doesn't work and ignoring the one that brings clients. We describe how to bring inquiries from different channels into one queue instead of several inboxes in query handling automation.

Property number in the inquiry

When a client asks about a specific apartment, you need to know which one. The form on the property card should have a hidden field with the listing number — this field goes to CRM along with the client's data. The agent sees: "Inquiry about unit at street X, listing number Y." They can check details immediately, instead of asking the client.

The same applies to phone inquiries — if the client calls about a specific listing, the number should be routed to the appropriate agent (based on property assignment), and the system should show that the call concerns listing number Z. This way the agent is prepared before answering the call.

Typical listing management mistakes that cost you clients

The first mistake is no price or "price negotiable" everywhere. The client doesn't know if they can afford the apartment and wastes time calling. If the price is negotiable, give a range — an illustrative example with assumed figures: "from 600,000 PLN" or "around 650,000 PLN." If you have a real price — give it.

The second mistake is the same photos for many properties. It happens that an agency uses one set of photos (e.g., office interior, view from window) for many different apartments. A client who sees two units with the same photos loses trust in the entire listing. Each property should have unique, current photos.

The third mistake is listings that hang for months after being sold. This shows the agency doesn't actively manage its database. Either there's no automatic update system, or no one regularly reviews the listings. The result? The client wastes time on outdated listings, and you lose trust.

The fourth mistake is missing metadata on the property card. Without datePosted and other schema.org RealEstateListing properties, it's harder to describe the listing unambiguously for search engines and other systems that read page data. And without a visible publication or update date, the client has no way to judge if it's worth calling.

The fifth mistake is no mobile version of the site or poor mobile optimization. More and more property inquiries start with browsing listings on a phone, on the way somewhere or during a break. If the site loads slowly, images don't adapt to the screen, and forms don't work on mobile — you're losing some potential clients before they even see the full listing.

Do it yourself in a week: a practical guide

If you want to organize your listings, don't wait for system implementation — start with what you can do yourself in a week. Each day, focus on one specific step.

Day 1: export a list of all properties from your site (via sitemap or manually from CMS) and from the portals where you publish. Save in a spreadsheet: URL, price, status (available/sold/removed), publication date, last update date.

Day 2: compare statuses and prices between your site and portals. Look for discrepancies — where does the price on the site differ from the portal? Where doesn't the status match? Mark all inconsistencies.

Day 3: analyze URLs for duplicates. Look for properties that appear under more than one address. Choose the canonical version and plan redirects.

Day 4: make decisions about sold properties. For each sold or removed listing, choose one option (leave with information, redirect, remove) and execute the action.

Day 5: implement source tagging in inquiries. If you use forms — make sure each form has a hidden field for source (site/portal/ad). If you don't have forms — start with a simple one, or at least tag the source in notes for each lead.

After a week, you'll have an organized database, a clear picture of where inquiries come from, and a foundation for further automation.

What it looks like in the system: automation that saves time

When you have organized processes, it's time to think about automation. A system that connects CRM, site, and portals works like this:

The property is entered into CRM once — with price, photos, description, location, and assigned agent. From CRM, automatic publication goes to the agency site (as a separate page with its own URL) and to all configured portals (via API or middleware). Each channel receives the same data from one source.

When the property status changes to "sold" in CRM — the system automatically updates the site and portals. You can set a rule: sold property disappears from portals after 7 days, but on the site it remains with "sold" information and links to similar available apartments. Or a rule: after 30 days from sale, the page 301-redirects to the page with new listings in that location.

When a client fills out a form on a property card — the inquiry goes to CRM with full context: property number, source (own website), client data, date and time. The system automatically assigns the lead to the agent responsible for that property and sends a notification. Additionally, you can set automatic follow-up — a reminder after 2 days if the agent hasn't contacted the client. What exactly happens to an inquiry after the first conversation is covered in follow-up automation.

This is how professional listing management works: instead of manually updating dozens of listings on many portals, you define rules in one place and let the system work. The agent can focus on conversations with clients, not on re-entering data between systems.

If you want to see how such a system works in practice, check out how the CRM and automations service works: one funnel for inquiries from every channel, without manual re-entry. You can also use the Integrations service, which connects the systems you already use (POS, calendar, CRM, spreadsheet) into one data flow, without replacing them, or build Websites and stores with a structure built around one visitor decision and measurement from day one. Each solution works independently, but together they create a complete ecosystem for managing a real estate agency.

Frequently asked questions

Do I have to publish listings on my own site, since they're on portals?

Your own site isn't mandatory, but it gives three advantages the portal doesn't provide. First, you control presentation — you can show the full object history, additional materials, comparisons. Second, you collect inquiries without the portal as intermediary — you get client data immediately. Third, you build visibility in Google for local queries, which the portal doesn't do. It's worth having your own site as a complement to portals.

How often should I update property statuses?

At minimum, once a month review all active listings. Check if prices are current, if statuses match reality, if there are any objects older than 60–90 days that are still marked as available. If you have automatic CRM synchronization, reviews can be less frequent, but the principle "always know what's sold" remains relevant.

What to do with a sold apartment on the site?

You have three options. First: leave the page with clear "sold" information and links to similar available apartments — you preserve backlinks and show that you have more offerings. Second: 301-redirect to the page with available listings in that location — the user immediately lands on something that might interest them. Third: remove the page and return 410 code — if there's no informational value left. Avoid leaving an empty page with code 200 — this generates a soft 404 error in Search Console.

How do I know which inquiries come from my site and which from portals?

You must tag the source in every inquiry. Easiest is through forms with a hidden "source" field — you set the value to "own website" on your site, to "Otodom" (or other portal) on the portal. For phone inquiries, you can use separate numbers for different channels or simply write the source in notes for each lead. Without this, you won't know which channel brings clients.

Is duplicate content on the site a problem for SEO?

It's not a policy violation or a penalty, but duplicate content can hurt user experience and waste crawl budget on addresses that don't matter anyway. If you don't specify a canonical address yourself, Google will try to pick one automatically — but it's better to do it yourself. For property listings in a real estate agency, the most important thing is to establish one canonical URL for each property and use rel="canonical" on all variants (filters, sorting, agent copies). This eliminates the problem without removing functionality.

How much does implementing automation for portal publishing cost?

It depends on the CRM you use and whether the portal provides an API. Some modern CRM systems for real estate agencies have built-in integrations with popular portals in Poland — then the cost is just the CRM subscription. If your CRM doesn't have integrations, you can build your own integration via API (first checking what the portal exposes) or use middleware tools. In any case, start with analysis — check if the portal even allows automatic publishing before investing.