NovA URL change should not reset the property’s internal history
Why a property can move to a new public URL without losing saved state, verification context, source history or its identity across the product.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A property page can move for ordinary reasons. A project is renamed, a section is reorganised, an old route is simplified, or a catalogue structure is rebuilt. The public URL changes because the website changes. The property itself has not suddenly acquired a new past.
I treat those as two separate layers. The URL is a route to an entity. The entity has its own continuity: saved state, source relationships, status history, verification context, images, comparisons and other connections. When the route changes but the real-world entity does not, that continuity should survive.
A new route is not a new property
Consider a hypothetical apartment that first appears at one page address and later receives a cleaner address after a site restructure. A buyer opening the new link should still be looking at the same apartment in the meaningful sense.
If a system creates a fresh record simply because the route changed, the result can look harmless at first. The new page renders correctly. The title is right. The photographs are present. Yet the old record may still hold the saved state, the last verification note or the relationship to an earlier comparison. The buyer now has two technical objects where there should be one property.
The reverse problem also exists: the old record may be discarded completely, taking useful history with it. Both failures come from treating a route string as the identity.
Saved state should follow the entity
A browser bookmark is only one form of return. A buyer may also save a property inside the platform, place it in a comparison, share it with a family member or return through an earlier conversation.
Those relationships should not depend on the exact spelling of the URL. If they do, a route migration becomes a user-data migration whether the team intended one or not.
I test this by creating context before the change. Save the property. Add it to a comparison. Open it through an older shared link. Then change the public route. Afterward, each path should still resolve to the same underlying property context. If the saved item disappears or a duplicate appears, the route has been given too much responsibility.
The object’s change history belongs to the object
Property information can evolve. A price may be reconfirmed, an area definition clarified, a project status updated, an image replaced or a stronger source added. Those changes are meaningful because they explain how the current state was reached.
A route migration should not wipe that lineage.
This does not mean exposing an internal audit log to every reader. Most technical events are not useful public information. It means keeping the substantive history attached to the entity so the product can distinguish “this fact was checked and later changed” from “we have no prior context.”
Without that continuity, a newly routed page can look artificially new. An old uncertainty may reappear as though nobody had already resolved it. A stale value may lose the marker that previously identified it as stale. The page address has changed, but the product’s memory should not.
Old links need the right continuation
Once a public URL has been shared, it becomes part of the buyer’s path. People place it in messages, notes and bookmarks. A migration therefore needs a sensible continuation for those old routes.
The implementation can vary. The user-facing requirement is simpler: an old link to a property should not silently land on a different property, a generic catalogue page with the original context removed, or a dead end when a clear successor exists.
This is where a technically correct redirect can still be insufficient. A redirect can send the browser to the new page while the platform loses the original saved relation, source history or comparison identity. The route transition works; the entity continuity does not. The two problems need separate tests.
A transition period must not create two truths
During a migration, an old route may remain in external links while a new route is already used in navigation. If the two representations are updated independently, facts can diverge.
One version may show a changed status while another retains an older price. Search may surface one, a saved list may use the other, and comparison may pull data from a third path. To the buyer, this is not a migration detail. It is a contradiction.
If both routes represent one entity, the underlying facts should have one authoritative state. The public address can vary during the transition without creating separate versions of the property.
Sometimes the entity really has changed
Continuity should not become an excuse to hide a genuine structural change. Suppose one broad project page is later split into distinct phases because each phase has independent facts. That is not merely a prettier URL. The underlying model has become more precise.
In such a case, the system may need to preserve the history of the former broad entity while creating clear relationships to the new phase entities. A buyer returning through an old link should understand what the new structure means, rather than being forced into an arbitrary phase as though nothing happened.
The principle is therefore not “a URL change can never affect identity.” It is “a URL change alone is not evidence that identity changed.”
I want the public route to behave like an address, not a passport. Addresses can move. The property’s internal history should continue unless the real meaning of the entity has changed as well. When that separation is respected, site maintenance remains maintenance instead of silently rewriting the buyer’s context.