Tag: XML Data Mapping

WordPress Custom Fields → XML Mapping → Portal-Ready Feed

Real estate agencies often manage their property listings in WordPress, but their data needs to be distributed across multiple property portals, each with its own XML structure, field names, location formats, and validation requirements.

In this project, the goal was to automate that process for two real estate websites and distribute their property portfolios to multiple international property platforms.

The Challenge

The client operated two real estate websites:

• sothebysrealty.me
• nekretnina.me

They wanted to automatically export their property portfolio to platforms including:

• Realting
• Homes Overseas
• Tranio
• A Place in the Sun
• Prian.ru
• Realitica
• Green Acres
• JamesEdition

Instead of manually entering or maintaining listings on each portal, the requirement was to create WordPress-based XML feeds that could automatically transform the existing property data into the format expected by each destination platform.

The initial requirement was relatively straightforward: generate XML feeds from WordPress.

However, the project quickly demonstrated that real estate feed integration is more than simply converting WordPress posts into XML.

Different portals required different:

• Field names
• XML structures
• Property types
• Location values
• Languages
• Feature/amenity mappings
• Publication rules
• Data formats
• Business rules

The source data therefore needed to be mapped and normalized before it could become a reliable portal-ready feed.

The Solution

The solution was implemented as a collection of custom WordPress feed integrations.

The basic architecture was:

WordPress Property Data → Field Mapping → Data Normalization → XML Generation → Portal-Specific Feed

Each portal received its own XML output while using the property’s existing information from the WordPress websites.

For example, a WordPress property could contain information such as:

• Property type
• Price
• Location
• Bedrooms
• Bathrooms
• Features
• Images
• Description
• Property ID
• Publication information

The feed logic then transformed these values into the XML structure required by the destination portal.

1. WordPress Data Extraction

The first step was extracting the existing property information from the two WordPress websites.

Rather than requiring the client to maintain a separate database for every portal, the existing WordPress property data remained the primary source.

This allowed the workflow to remain simple:

Edit the property once in WordPress → Generate the required XML → Portal consumes the feed.

The project eventually evolved into a broader multi-portal feed system rather than a single XML export.

2. Portal-Specific XML Mapping

Each portal had its own requirements.

For example, the client supplied the Homes Overseas export specification, while Realting provided an XML sample/template for its import structure. The implementation therefore required studying the destination specifications before creating the mapping.

The mapping process connected the WordPress property fields to the corresponding portal fields.

A simplified example:

WordPress Data	Portal XML
Property ID	<property_id>
Property Type	Portal-specific property type
Price	Portal price field
City	Portal location field
Bedrooms	Bedroom element
Features	Portal feature elements
Images	Portal image elements
Description	Portal description field

The important point is that this was not a one-to-one XML conversion.

The same WordPress value could need to be transformed differently depending on the destination portal.

3. Location Normalization

Location mapping became one of the important parts of the project.

The source websites and destination portals did not always use identical city or location names.

This required custom location mapping so that a WordPress location could be translated into a value recognized by the destination portal.

The project included additional work specifically for mapping locations where the website’s city names did not match the Green Acres database.

This illustrates an important lesson from real estate feed development:

Valid XML does not necessarily mean valid portal data.

A feed can be technically correct XML and still be rejected or incorrectly categorized by the receiving marketplace if its values do not match the portal’s expected taxonomy.

4. Property Type Standardization

Property types also required normalization.

The source website could use one naming convention while a portal could expect a different set of property categories.

The project included property-type mapping as part of the broader feed system, and a later website change to the property’s type name even caused multiple existing feeds to require correction.

This highlighted the importance of making feed integrations resilient to changes in the source WordPress data structure.

5. Multilingual Feed Support

The project also required English and Russian feed variations for some portals.

Separate feed endpoints were created for the different language requirements, with the additional work involving fetching translated data rather than simply duplicating the original XML.

This meant the feed system had to consider:

Source language → Translation → Portal-specific XML

rather than simply:

Source language → XML

6. Duplicate Prevention

Another requirement was preventing the same property from being unnecessarily copied to advertising platforms.

A custom WordPress function was developed to provide an option on the property edit screen to control whether a property should be copied to another website.

This introduced a simple but important business rule:

Property enabled for distribution → Include in feed

Property disabled for distribution → Exclude from feed

That gave the client more control over which listings were syndicated.

7. Feed Validation and Testing

Generating XML was only one part of the work.

The feeds also needed to be tested against the destination requirements to make sure:

• Required fields were present
• Values were correctly mapped
• Locations were recognized
• Property types were accepted
• Images were included correctly
• Duplicate listings were controlled
• Portal-specific XML structures were followed

The later multi-portal project explicitly included feed validation and testing as part of the implementation scope.

The Project Expanded Over Time

What began as a small requirement for two websites and two portals gradually became a much larger feed ecosystem.

The initial implementation covered:

2 WordPress websites → 2 destination portals

It subsequently expanded to additional portals and integrations, including A Place in the Sun, Prian.ru, Realitica, Green Acres, and JamesEdition.
The work also included merging feeds, additional location mappings, and handling portal-specific limitations.

For example, during the Green Acres integration, some properties could not be added because the portal did not support the source property’s “price upon request” value.

This is a good example of why portal integrations often require more than coding alone: some limitations originate from the destination platform itself.

The Result

The project evolved from a basic XML export into a reusable multi-portal real estate feed system.

The resulting workflow allowed property information maintained in WordPress to be transformed into portal-specific XML feeds without manually recreating every listing on every platform.

The overall process became:

Manage Property in WordPress

↓

Apply Mapping & Business Rules

↓

Normalize Location / Property Type / Features

↓

Generate Portal-Specific XML

↓

Validate Feed

↓

Publish to Real Estate Portal

This significantly reduced repetitive data entry and made it possible to distribute listings across multiple real estate marketplaces using automated feeds.

Key Takeaways

1. XML generation is only the beginning

A technically valid XML document is not enough. The receiving portal must also understand the values and structure.

2. Mapping is the core of real estate feed development

Property types, locations, features, languages, and other fields often need normalization before they can be exported.

3. Every portal is different

A feed designed for one marketplace should not automatically be assumed to work for another.

4. Source data changes need to be considered

A change to a WordPress field name or property-type value can affect multiple downstream feeds.

5. Business rules matter

Options such as excluding a property, preventing duplicates, handling missing values, or dealing with unsupported pricing models can be just as important as the XML structure itself.

The Architecture in One Diagram

WordPress Websites

sothebysrealty.me + nekretnina.me

↓

Property Data Extraction

↓

Field Mapping

• Property type
• Location
• Price
• Features
• Images
• Languages

↓

Data Normalization

↓

Portal-Specific XML Generator

↓

Validation & Testing

↓

Real Estate Portals

• Realting
• Homes Overseas
• Tranio
• A Place in the Sun
• Prian.ru
• Realitica
• Green Acres
• JamesEdition

Final Outcome

The project demonstrates how a WordPress website can become the central source of truth for a real estate company’s property portfolio while custom XML integrations handle the differences between external marketplaces.

Instead of maintaining property data separately on every portal, the workflow becomes:

Update once in WordPress. Transform automatically. Distribute everywhere.

That is the real value of a custom real estate XML feed: not just generating XML, but building a reliable bridge between WordPress property data and the specific data requirements of each marketplace.

Technologies: WordPress · PHP · Custom Plugins · XML · Data Mapping · Feed Validation · Real Estate Portal Integration