Coming soon to sold: what a listing page should show at every status

A listing page is not one page, it is five: the same URL doing a different job at each stage of the listing’s life. Coming soon, active, under offer, sold and withdrawn each call for different content, a different primary call to action, a different enquiry destination and a different indexing posture, and the brokerage that builds those five states once, driven by the status field in the feed, stops spending staff time on updates that should never have been manual. This article covers what each state shows, why a sold page should keep its URL forever, and how to stop a growing sold archive from crowding out the inventory you are actually trying to sell.

Why the lifecycle is the right way to model a listing page

A listing page exists for a property that keeps changing state, so a page built as one fixed template is wrong for most of its life. The mistake is designing the page for the active state, which is where it spends the most attention but often not the most time, and then patching the other states by hand when someone remembers.

Modelling it as a lifecycle means deciding, once, what happens at each state across five dimensions:

• Content. What is shown, what is hidden, what is added.
• Primary call to action. The single thing the page asks a visitor to do.
• Enquiry routing. Who receives the enquiry and what it is recorded against.
• URL and indexing. What the URL does and whether the page stays in the index.
• Inventory role. Whether the listing counts toward market page totals and appears in browsing surfaces.

Decided that way, the status field coming out of your feed drives the page. Nobody edits anything. The alternative, which is a marketing coordinator working through a list every Monday, fails in exactly the way manual processes fail: on the busy weeks, which are the weeks with the most status changes.

Coming soon

A coming soon listing is not yet available to show, so the page’s job is to capture interest and set expectations rather than to book a viewing it cannot deliver.

What the page shows

Show enough to make the listing real without pretending it is live. That usually means the address or the neighborhood depending on what your MLS permits at this stage, the headline specs, a limited set of photos, and a clearly labeled status with an expected on-market date if one is published. The label should be unmissable rather than a small badge in a corner, because a visitor who scrolls past it and assumes the property is available will be annoyed twice: once when they cannot book, once when they find out.

What to leave out matters as much. Full galleries, floor plans and any showing scheduling interface should wait, partly because some of that material is genuinely not ready and partly because showing a disabled scheduler is a worse experience than not showing one.

Primary call to action

One action: notify me when this goes active. Not a showing request, not a generic contact form. An interest registration is honest about what the page can deliver, and it produces a genuinely useful list, because the people who register interest on a coming soon listing are self-selecting as motivated and patient.

Enquiry routing and inventory role

• Route to the listing agent or the assigned point of contact, recorded against the listing rather than sent to a shared inbox.
• Hold the registered contacts against the listing so the notification at go-live is automatic rather than a manual send.
• Count coming soon listings separately from active in market page totals. A market page claiming eleven active listings when three of them cannot be shown is quietly wrong.
• Keep coming soon listings visible in browsing surfaces, clearly labelled and usually sorted below active inventory.

Active

An active listing page is the one everything else is measured against, and its job is to give a buyer enough to decide to see the property in person.

What the page shows

The full set: complete photo gallery served as real, correctly sized images, full specifications, description, map and location context, floor plans where available, and the required attribution and source disclosure. This is also the state where page weight is most at risk, because a listing page with thirty photos is the heaviest page a brokerage site has, and the photos are the reason people are on it.

Primary call to action

Request a showing, with a secondary ask for the people not ready to commit to a visit: ask a question, or save the listing. Two actions, clearly ranked, is the pattern that works here. Three or more competing buttons is how a page stops having a primary call to action at all.

Enquiry routing and inventory role

• Route to the listing agent, with a defined fallback if they do not respond inside a set window, because an unanswered enquiry on an active listing is the most expensive failure in this entire lifecycle.
• Record the enquiry against the listing and the agent so response times are measurable per listing rather than per office.
• Count toward market page active totals and appear in every relevant browsing surface and filter by default.
• Include in the sitemap and keep indexable.

Under offer or pending

An under offer listing is not soliciting showings, but it should stay visible rather than disappear, because the page is still receiving search traffic and the deal is not done.

What the page shows

Everything the active page showed, plus a clear status label, minus the showing scheduler. The photo gallery and the specs stay. Removing content at this stage makes the page worse for the person who arrived from search and better for nobody. Whether the price stays visible depends on your MLS display rules at this status, which is one of the questions worth settling before the template is built rather than after.

Primary call to action

Register interest as a backup, phrased plainly. A buyer landing on a pending listing already knows they are late, and a page that acknowledges that and offers a realistic next step performs better than one that either hides the status or keeps a showing button that produces an awkward phone call.

A useful secondary action here is “show me similar active listings,” because a meaningful share of this traffic is genuinely in the market and looking at this property only because it matched a search. That link should go somewhere specific, such as the market page or a filtered set matched on property type and price band, not to a generic search page.

Enquiry routing and inventory role

• Route backup enquiries to the listing agent, flagged as backup so they are triaged differently from a live showing request.
• Remove from active counts on market pages, and either exclude from default browsing surfaces or show clearly labelled and sorted below active listings.
• Keep indexable and keep the URL unchanged.

Sold or closed

A sold listing page keeps its URL permanently, changes state to sold, and turns into a useful entry point rather than a dead end or an invitation to enquire about something that no longer exists.

What the page shows

A plain statement that the property sold, the status label, and whatever your MLS agreement permits you to continue displaying at this status, which varies and may require removing the price, restricting the gallery, or limiting how long the record stays up at all. Settle that with your MLS before the template is built, because the compliance answer decides the design.

What the page gains is the part most brokerages skip: real onward paths. Links to comparable active listings in the same market and price band, a link to the market page, and a route to the listing agent for someone who wants to talk about a similar property. The page has a visitor. It should give them somewhere to go.

Avoid turning a sold page into a sales pitch about the outcome. This is a brokerage website, not a highlight reel, and specific claims about how a sale performed stray into territory a website should not narrate.

Primary call to action

See similar active listings. That single action, pointed at a real filtered set rather than a blank search page, is what converts sold-listing traffic into something useful. A secondary contact option belongs there for the person who wants a conversation, but it should not lead.

Enquiry routing and inventory role

• Route to the listing agent by default, since they know the property and the market, with an office fallback if the agent has left the brokerage.
• Remove from active counts everywhere: market page totals, homepage counters, feed exports.
• Exclude from default browsing surfaces, and make the sold archive its own browsable section rather than a filter buried in the main search.
• Keep the URL and keep the page reachable.

Withdrawn, expired or removed from the feed

A listing that leaves the feed is a different case from a sold listing, because the record may no longer be licensed for display at all, and the handling has to be automatic.

What the page shows

This is the state where the correct answer depends entirely on your agreement. Broadly there are three permitted patterns, and you should know which one applies before launch:

1. Continued display with an off-market label. The page stays, the status reads off market, and the onward links do the work, the same way a sold page behaves.
2. Redaction. The page stays at the same URL but the restricted content is stripped, leaving the address, a status, and the onward paths.
3. Removal. The record cannot be displayed, so the page must come down. In that case it needs a redirect to the most relevant surviving page, usually the market page, rather than being deleted into a dead link.

Why “removed from feed” must be its own state

Treating removal as the same thing as sold is a common and quietly damaging shortcut. A listing that expired was not sold, and a site that labels it sold is publishing something untrue. The RESO Data Dictionary’s standard status vocabulary distinguishes these cases explicitly, which is exactly why your mapping layer should preserve the distinction rather than collapse everything that is not active into one bucket.

Why deleting a sold listing page is a mistake

Deleting a sold listing page throws away an asset your brokerage already paid for and creates a broken link for everyone who saved, shared or linked to it.

What you lose

• Accumulated links. Any link pointing at that URL, from a portal, a partner site, a social post, an agent’s email signature, now points at nothing.
• Bookmarks and message links. Buyers save listing links. Sellers send them to family. A deleted page turns every one of those into an error page.
• Search history for that URL. The page had been discovered, crawled and indexed. Deleting it discards that entirely rather than redirecting the value somewhere.
• A live entry point. While the page exists, it is the only page on your site that answers an exact-address query for that property. Delete it and nothing on your domain does.

Google’s own documentation on HTTP status codes explains that a page returning a not-found response is treated as gone and dropped from the index, which is the correct behavior for a page that genuinely no longer exists and a waste for a page you chose to delete.

What to do instead

The rule is short. Keep the page, change the state, restrict what compliance requires you to restrict, add onward links to comparable active inventory, and never remove the URL. If the record truly cannot stay up, redirect rather than delete: Google’s guidance on redirects describes a permanent redirect as the way to tell search engines that content has moved, which passes the accumulated signal to the destination instead of discarding it.

The only case for changing a listing URL at all is a genuine correction, such as a misspelled street in the slug. Even then the old URL redirects permanently to the new one, and Google’s guidance on consolidating duplicate URLs is the reason: leaving two live URLs for one listing forces search engines to choose between them, which splits the signal rather than doubling it.

How status changes should propagate from the feed

Status changes should reach the page automatically, mapped from the feed’s own status vocabulary into your display states, with no human in the loop.

The pipeline has four parts, and each is worth naming because each fails differently:

1. Ingest. The sync pulls changed records, with status among the highest-frequency fields. If your agreement caps polling, status is the field to spend that budget on.
2. Map. Source status values are normalized into your five display states through one mapping table, not through conditionals scattered across templates. The RESO Data Dictionary’s standard status enumerations are the sane target, because they survive a change of MLS.
3. Apply. The page state changes: content blocks, the primary call to action, the enquiry routing rule, the indexing directive, the inventory counts. All of it derives from the state, so none of it can drift out of sync with the label.
4. Propagate. Everything downstream updates in the same pass: market page counts, browsing surfaces, the sitemap, the search index, any feed export, and any cached copy of the page.

That last step is where most implementations leak. The listing page says sold and the market page still counts it as active, because the count was cached and nothing invalidated it. The rule that prevents this is that a status change invalidates every surface that mentions the listing, not just the listing page.

It is also worth logging status transitions with timestamps. When someone asks why a page showed the wrong status on a Tuesday, a transition log answers in a minute and a guess takes a day.

Schema and indexing implications

Structured data on a listing page should describe what the page currently shows, which means it has to change with the status rather than being written once for the active state.

Keeping markup honest

Google’s introduction to structured data markup is explicit that markup should represent the content visible on the page. A status change is the most common way a brokerage site breaks that rule by accident: the visible page says sold, and the markup left behind from the active state still presents the property as available. Deriving the markup from the same state object that drives the visible content is the fix, because then the two cannot disagree.

Indexing posture by state

• Coming soon, active, under offer: indexable, in the sitemap, canonical to itself.
• Sold: indexable by default, in the sitemap, canonical to itself. There is no search reason to hide a sold page, and there are good reasons to keep it reachable.
• Removed from feed, display not permitted: the page goes, and the URL redirects permanently to the market page rather than returning a not-found.
• Any thin state page you cannot make useful: if a state leaves the page with nothing but a label, a noindex directive is the honest option. Google’s documentation on blocking indexing with noindex describes it as the way to keep a page out of results while it remains reachable, which fits a page you want to serve to a person with a bookmark but not to surface in search.

One more rule that saves trouble later: the canonical URL never changes with status. Same listing, same canonical, whatever state it is in.

Keeping a sold archive from crowding out active inventory

A growing sold archive only becomes a problem when sold pages are mixed into the same surfaces as active inventory, so the fix is separation rather than deletion.

Over a few years a brokerage running volume accumulates more sold pages than active ones, often many times over. Left unmanaged, that changes what the site is: browsing surfaces fill with unavailable properties, internal links point mostly at things nobody can buy, and a visitor who wanted to see what is for sale has to work for it.

Separation, in practice:

• Default every browsing surface to active inventory. Sold is a deliberate choice a visitor makes, never a default filter state.
• Give the sold archive its own section. A browsable, paginated area with its own entry point, rather than sold listings interleaved into the main search results.
• Keep counts honest. Market page totals, homepage counters and category counts show active inventory. If you also show sold totals, label them separately.
• Point internal links at active pages first. Related listings on a sold page link to active comparables. Related listings on an active page do not link to sold pages.
• Keep market pages weighted to what is available. A market page leading with sold inventory answers a question nobody asked, since the search that brought them there was about what is for sale.
• Prune media rather than pages. If storage or page weight is the concern, reduce the gallery on old sold pages to a small set. Keep the page, keep the URL, shed the bytes.

The archive is genuinely useful at that point. It answers address searches, it holds accumulated links, and it feeds people toward current inventory. It just does not get to sit in the front of the shop.

Building it once

The whole argument compresses to one operational point: define five states, attach the five dimensions to each, wire the state to the feed’s status field, and let every surface on the site read from that state. Build it that way and a status change is a data event with no staff cost attached. Skip it and every status change becomes somebody’s Monday.

To see the five states implemented against a real feed and roster, book a demo or read the features breakdown. The companion articles on brokerage website architecture and IDX, MLS and feed integration cover the page structure and the data connection this lifecycle depends on.