From One Custom XML Feed to a Multi-Portal Property Distribution System
Real estate websites often need to distribute property listings to multiple portals, marketplaces, advertising platforms, and property aggregators. The challenge is that each platform can require a completely different XML, JSON, or CSV structure, while the source website may use a WordPress theme such as Houzez with custom fields, taxonomies, multilingual data, and different measurement formats.
This case study describes a long-term project for a real estate website using WordPress, Houzez, WP All Import, and WP All Export.
The project began with a relatively small requirement: fixing several fields in an existing WP All Export template for a property portal. Over time, the requirement expanded into a collection of custom feeds and ongoing feed maintenance.
The initial client requirement included generating property feeds for external portals while continuing to use the existing WP All Export setup where possible. The client specifically needed help with image URLs, furniture/status values, and conversion of Thai land measurements such as square wah and rai into square metres.
The Initial Challenge
The client’s WordPress website contained property data in different formats.
Some of the major challenges included:
- Multiple property images needed to be output as individual URL elements.
- Values such as “Furnished” needed to be cleaned before being sent to the destination portal.
- Status values required transformation.
- Land measurements could be stored as square wah, rai, or combined formats such as Rai-Ngan-Wah.
- Property types needed to be mapped from WordPress parent/child categories into the destination portal’s terminology.
- Virtual-tour information needed to be converted into the format required by the portal.
- Different portals required different XML structures.
The first approach was to see whether the existing WP All Export template could be modified rather than immediately replacing it with a custom plugin. A custom plugin was kept as the fallback option if the existing export system could not handle the requirements.
This approach helped avoid unnecessary redevelopment and allowed the existing WordPress workflow to remain part of the solution.
Phase 1: Proppit XML Feed
The first major deliverable was a custom XML feed for Proppit.
The feed was initially developed around the client’s existing property data and then refined based on real output and feedback.
One important requirement was converting land measurements and removing decimal values from both land area and floor area. The feed was subsequently updated to round floorArea and plotArea.
Complex Property Data Mapping
The project involved more than simply copying WordPress fields into XML tags.
For example, property types had to be interpreted according to the destination portal’s requirements. Later revisions included distinguishing between residential and commercial property types and mapping categories such as:
- House
- Condo
- Townhouse
- Shophouse
- Office
- Hotel
- Factory
- Retail space
The client provided examples where a property could have multiple WordPress categories, requiring custom logic to determine which category should become the primary destination value.
This illustrates an important aspect of custom feed development: source taxonomy and destination taxonomy rarely match one-to-one.
Diagnosing WP All Export
An interesting technical problem appeared when the WP All Export template worked in Preview mode but failed during the actual export.
Testing showed that individual properties could be exported successfully and that reducing the number of XML tags allowed all 88 properties to process. The investigation indicated that the problem was likely related to the number of database queries and server resource limitations during the larger export.
The recommendation was to investigate hosting limits such as maximum execution time and memory rather than incorrectly blaming the property data or custom functions.
Meanwhile, the custom feed continued to provide a working alternative.
This was an important distinction:
A feed can be logically correct while the export mechanism used to generate it is still limited by server resources.
Virtual Tour and Feed Formatting Fixes
The Proppit feed later required the virtual-tour field to contain a direct link rather than embed code.
The feed was updated accordingly.
A further issue appeared where one property was receiving an incorrect virtual-tour base URL because different properties could use different virtual-tour providers.
The feed logic was adjusted so that the property-specific virtual-tour URL could be handled correctly rather than applying one universal URL to every listing. The client confirmed that the corrected virtual-tour link was displaying properly.
Expanding Into Multiple Feeds
After the initial Proppit implementation, the project expanded significantly.
The client requested additional feeds for other real estate platforms and advertising systems, including:
- Thailand Housing Market
- Baan Finder
- Living Insider
- Facebook Commerce Manager
- Google-related feeds
- Google Ads real estate CSV
- Green-Acres
- Nestopa
- Propertyhub JSON
- XML2U / Properstar-related distribution
The client also maintained a Google Sheet to track the different feeds and requirements.
This changed the nature of the work from a one-off XML customization into an ongoing multi-feed property distribution system.
Google Feed and Local Inventory
The Google feed required additional destination-specific fields and formatting.
Updates included:
- Resolving line-break formatting.
- Removing an unwanted price prefix.
- Adding
store_code.
- Adding
quantity.
- Creating a separate feed for local inventory because the destination required a different filename.
The primary Google feed and Proppit feed were updated accordingly.
A separate local inventory feed was subsequently created:
google_local_inventory_xml_feed.xml
The feed was also repaired after a PHP version change caused the XML feeds to stop working. The client had moved the hosting environment to PHP 8.2.4, and the feed plugins were upgraded to work with the newer environment.
This demonstrated another recurring challenge with WordPress feed systems: hosting and PHP environment changes can affect custom feed code even when the property data itself has not changed.
Facebook Commerce Manager Feed
The project also expanded into a Facebook Commerce Manager XML feed.
The feed required destination-specific handling for fields such as:
- Property type
- Pet policy
- Area size
- Neighborhood
- Address information
- Page ID
- Security deposit
- Utilities
- Video
The feed was revised several times based on Facebook’s validation feedback. Eventually, the video field was removed because the destination required a direct downloadable video URL rather than a normal video-hosting page URL.
This is another example of why feed development is not simply an XML-generation exercise. The destination platform’s validation rules must be incorporated into the transformation logic.
Baan Finder and Living Insider
The next stage involved creating feeds for Baan Finder and Living Insider.
Baan Finder required more complex property-type mapping.
For example, a property categorized as commercial on the WordPress website could still need to be mapped to SHOPHOUSE, HOTEL, FACTORY, OFFICE, or another destination-specific type depending on information contained in the title or description.
Living Insider introduced another layer of complexity around land measurements.
Different fields were required depending on property type, including:
- Square metres
- Square wah
- Rai
- Ngan
- Wah
- Separate land-area components
- Thai and English titles/descriptions
- Condo-specific values
- Multiple image URLs
The client specifically identified cases where a value such as 174 square wah needed to be separated into the appropriate Rai/Ngan/Wah fields rather than simply placing the entire number into one field.
Green-Acres Integration
In 2025, another feed was added for Green-Acres.
The feed was developed as a dedicated XML integration and subsequently updated with destination-specific fields including:
- English title
- Province
- Sub-district/district
- Property ID
- Favorite status
- Included fees
- Agency rate type
After submission, the destination platform reported a video URL problem. The video URL issue was diagnosed and corrected, after which the feed was reported as working.
Long-Term Feed Maintenance
One of the most interesting aspects of this project is that the work did not end after the initial feed development.
As the website, destination platforms, hosting environment, and property data changed, new requirements continued to appear.
Examples included:
- New destination validation rules.
- Changes to property classifications.
- New PHP versions.
- Different language requirements.
- Changes to virtual-tour providers.
- New property filtering requirements.
- Feed performance concerns.
- Listing limits imposed by external platforms.
- Changes in external APIs.
- New image-handling requirements.
For example, in 2025 the client became concerned about the number of listings being refreshed on Properstar. A strategy was discussed to change only a limited number of property IDs per day instead of changing all IDs simultaneously. The proposed approach was approximately 15 listings per day for a 500-listing cycle.
Later, Nestopa introduced a limit on the number of listings displayed under its free plan, leading to another requirement to prioritize particular property listings and control how frequently listing IDs changed.
This shows how a feed system can evolve into a business-rule engine, rather than remaining a static XML generator.
Feed Filtering and Automation
As the number of feeds increased, the client wanted greater control over which properties were included.
The proposed feed-management logic included filtering by:
- Property ID prefixes.
- Minimum sale price.
- Minimum rental price.
- Custom fields.
- Specific properties to include.
- Specific properties to exclude.
- Property status.
- Other feed-specific conditions.
For example, a custom field such as fave_luxury = Yes could be used to select properties for a particular luxury-property feed.
This approach provided much greater flexibility than hard-coding a completely different selection rule into every feed.
Performance Became a Separate Challenge
As the number of properties and feeds increased, feed-generation performance became an important concern.
The client reported that some XML URLs could take several seconds to load and, in some cases, make the browser appear unresponsive.
The website developer subsequently implemented Redis caching for the feed outputs. According to the project discussion, the site was generating approximately 15 XML/JSON feed outputs from more than 800 properties and many custom fields. The caching layer was intended to make repeated feed requests significantly faster and automatically refresh the cache after imports.
The project therefore evolved beyond field mapping into considerations involving:
- Database queries
- Feed generation performance
- Caching
- Import/export workflows
- Background processing
- Feed refresh cycles
Handling Large Feeds
Another scalability issue emerged when Living Insider imposed a limit of 1,000 records per XML or CSV file.
Instead of allowing the feed to grow indefinitely, the proposed solution was to introduce pagination so the listings could be divided into multiple parts.
This is a useful example of designing around an external platform’s technical limitations rather than trying to force the destination to accept an oversized feed.
Land Measurement Standardization
The project eventually exposed a larger architectural issue: property data from different agencies did not use a consistent land-measurement format.
Some providers supplied:
- Square wah
- Square metres
- Rai
- Rai + square wah
- Rai + Ngan + square wah
The client wanted to establish a consistent base measurement that could then be converted into other units.
The requirement included creating import-side PHP logic so that incoming data could be normalized before it was used by the different feeds. The client specifically identified mixed-data providers such as Perfect Homes and Isara Real Estate as requiring special handling.
This was an important shift from feed-level conversion to data normalization at the source/import level.
Once data is normalized properly, multiple feeds can use the same underlying property values instead of implementing independent conversion logic repeatedly.
Extending the System Beyond XML
The project also expanded beyond traditional XML feeds.
The client wanted to generate CSV data for a video-generation platform called CreateOMate, with the eventual goal of connecting the data to automation tools for social media publishing.
The CSV needed to contain:
- Individual photo URLs in separate columns.
- A specific location structure.
- Child property categories rather than parent/child category strings.
- Conditional price formatting.
- Potential HTML cleanup.
The existing WP All Export template was modified using PHP functions to support these requirements.
This demonstrated that the same WordPress property database could serve many different downstream purposes:
Website → XML feeds → JSON feeds → CSV exports → advertising → social-media content
What Made This Project Challenging?
The biggest challenge was not creating XML syntax.
The real difficulty was translating one complex real estate database into multiple destination-specific data models.
The same property could require different:
- Property types
- Measurement units
- Language values
- Address structures
- Image formats
- Video formats
- Status values
- Price formats
- Filtering rules
- Required fields
- Optional fields
A field that worked correctly for one destination could be wrong for another.
For example, HTML formatting could be useful in one feed but unacceptable in another. Similarly, a universal property-type rule could create incorrect classifications when a property had multiple categories.
The project therefore required continuous validation against the actual destination requirements.
Results
The project evolved from a single custom XML-feed requirement into a long-term feed-development and maintenance relationship.
The conversation records show work involving multiple destination feeds and formats, including Proppit, Google, Facebook, Thailand Housing Market, Baan Finder, Living Insider, Green-Acres, Nestopa, Propertyhub, and XML2U/Properstar-related integrations.
The client repeatedly returned with additional feed requirements and described the collaboration positively. At one point, after multiple feed updates, the client stated that it was “great to have been able to make this contact” and asked to continue with additional feeds.
The relationship subsequently continued into later years with additional feed modifications, filtering, performance, listing-refresh, and data-normalization requirements.
Key Lessons From the Project
1. Start With the Existing System
The initial goal was not to replace WP All Export unnecessarily. The existing workflow was investigated first.
This can reduce development time and preserve the client’s familiar workflow.
2. Normalize Data Where Possible
Repeated conversion logic across individual feeds can become difficult to maintain.
Standardizing data during import can make downstream feeds significantly easier to manage.
3. Every Portal Has Different Rules
There is no universal “real estate XML feed.”
Each destination may have different requirements for:
- Categories
- Measurements
- Images
- Descriptions
- Languages
- Videos
- Pricing
- IDs
- Filtering
4. Feed Development Requires Real-World Testing
A feed can be valid XML and still be rejected by the destination.
The project repeatedly required testing against actual portal feedback and adjusting the mapping accordingly.
5. Scaling Changes the Architecture
As the number of properties and feeds grows, performance becomes important.
Caching, filtering, pagination, and controlled refresh cycles may become just as important as the XML mapping itself.
6. Feed Maintenance Is Often More Valuable Than One-Time Development
External platforms change their requirements.
Websites change their data structure.
Hosting environments change.
New property sources are added.
New portals are introduced.
A feed that worked perfectly when created may require maintenance months or years later.
Conclusion
This project is a good example of how a seemingly small WordPress XML-feed request can evolve into a much broader data-integration system.
What started as a request to fix several fields in a WP All Export template eventually involved custom XML, JSON, and CSV feeds; complex property-type mapping; Thai land-measurement conversion; multilingual data; virtual tours; image handling; filtering; pagination; caching; PHP compatibility; external-platform validation; and long-term maintenance.
The central lesson is simple:
A successful real estate feed is not just an XML document. It is a data-transformation layer between the property’s source database and the unique requirements of every destination platform.
When that transformation layer is designed carefully, the same WordPress property database can support many different portals and marketing channels without requiring the property data to be manually recreated for every platform.