WP to XML

Category: Case Studies

  • Case Study 14: Custom Real Estate XML Feed Integration for International Property Portals

    Client Background

    A real estate agency based in Spain approached us with approximately 750 property listings stored in a multi-agency property database. The agency already had several XML feeds but needed a new custom XML feed for a German property portal with very specific technical and data requirements.

    The client wanted the feed to follow the receiving portal’s specification precisely rather than simply exporting the existing property data.

    The Challenge

    The main challenge was creating an XML feed that could:

    • Retrieve property information from the client’s external property database.
    • Transform the available property data into the required XML structure.
    • Follow the receiving portal’s exact XML specification.
    • Support the required API-based delivery process.
    • Work independently of the client’s main website.

    The client initially shared their website, but after reviewing the requirements, it became clear that the primary data source was Resales Online, rather than the agency’s WordPress or website content.

    This distinction was important because the XML feed did not need to be generated from the agency’s public website. Instead, the integration needed to work with the external property database and the receiving portal’s requirements.

    Understanding the Data Source

    The client’s properties were maintained through the Resales Online network. The project therefore required access to the relevant property database rather than relying on the agency website.

    After discussing the architecture with the client, we clarified that website access was not required. Instead, the integration would use the appropriate database/API access and a hosting environment capable of running the PHP-based conversion script.

    This helped simplify the implementation and avoided unnecessary changes to the client’s existing website.

    German Portal Requirements

    The receiving company provided technical specifications explaining that XML data had to be submitted through its REST API according to its own XML specification.

    The client supplied the technical documentation for the receiving platform, including information about its Import API and Import/Export API. The receiving company also indicated that use of the API was subject to its own service requirements and fees.

    This meant the project was more than simply producing an XML file. The feed had to be structured and prepared in a way compatible with the receiving portal’s technical requirements.

    API Access and Authentication

    During implementation, it became necessary to obtain the appropriate API credentials from the receiving platform.

    The client was guided through the API permission process and the relevant self-service area for generating API credentials. When necessary, the client also provided account access so that the integration work could proceed.

    Authentication was coordinated with the client because the platform required additional verification during login. The client provided the required verification code while the integration was being configured.

    Solution

    The solution involved creating a custom XML feed specifically around the client’s external property data source and the receiving portal’s requirements.

    The general workflow was:

    Property Database → Data Retrieval → Data Transformation → Custom XML Generation → Portal/API Delivery

    The approach avoided modifying the client’s main website and instead focused on the data integration layer.

    A separate PHP-capable hosting environment could be used to execute the conversion script, allowing the feed generation process to operate independently from the public-facing real estate website.

    Project Delivery

    The initial project was agreed including revisions and source code.

    The project required communication between three important components:

    1. The real estate agency
    2. The external property database
    3. The receiving property portal

    This made requirement clarification particularly important before development began.

    A Successful Follow-Up Project

    The relationship continued after the initial XML feed project.

    On March 17, 2025, the same client returned with another requirement: an XML feed for Idealista, a Spanish property portal.

    The client explained that Idealista required the feed developer to contact them directly to obtain the XML feed specification. The new feed was expected to be similar to the previous integration, but without the translation requirement used for the earlier project.

    A new custom offer was subsequently prepared to develop a feed specifically for Idealista.

    Key Lessons

    1. Identify the Real Data Source First

    A client’s public website is not necessarily the source of truth for a real estate feed.

    In this project, the agency website was initially shared, but the actual property data was maintained through an external property database. Identifying this early prevented unnecessary work on the website.

    2. Follow the Receiving Portal’s Specification

    International property portals often have their own XML structures, required fields, APIs and authentication procedures.

    A successful feed therefore needs to be designed around the destination portal’s specification, not simply around the source database.

    3. Separate Website Development From Feed Integration

    Because the client’s website was not required for this integration, the feed could be developed independently.

    This approach reduces the risk of interfering with an existing production website and makes the integration easier to maintain.

    4. API Credentials Are Part of the Integration

    XML feed development can involve more than XML formatting. When the destination platform requires REST API submission, authentication and API permissions also become part of the technical workflow.

    5. A Good Integration Can Lead to Repeat Business

    One of the strongest outcomes of this project was the client’s return for another XML feed shortly afterward.

    The second request for an Idealista feed demonstrated that successful completion of one portal integration can establish trust for additional international property-feed projects.

    Conclusion

    This project demonstrates how a custom real estate XML feed can connect an external property database with an international property portal without requiring changes to the agency’s main website.

    The key was understanding the actual data source, reviewing the destination portal’s technical requirements, obtaining the necessary API access, and building the feed around the receiving platform’s specification.

    The subsequent Idealista request from the same client further demonstrated the value of delivering a practical, portal-specific XML integration that can be extended to additional property platforms.

    Project Type: Custom Real Estate XML Feed
    Data Source: External Multi-Agency Property Database
    Integration: Custom XML + REST API
    Follow-Up: Idealista XML Feed Integration

  • Case Study 13: Building and Maintaining Custom Real Estate XML Feeds for a Multi-Website Property Business

    Client Overview

    The client operates multiple real estate websites and needed custom XML feeds to distribute property listings to different property networks and platforms.

    The initial requirement was relatively simple: create an XML feed compatible with the Houzez WordPress real estate plugin.

    What started as a single-feed project developed into a long-term technical collaboration involving multiple websites, property-feed formats, custom filtering rules, additional XML fields, feed troubleshooting, and performance improvements as the number of listings grew.

    The project began in May 2023 and continued through subsequent feed development and maintenance requests.

    The Challenge

    The client needed to connect WordPress-based real estate websites with external property networks using specific XML formats.

    The main challenges included:

    • Generating XML feeds from WordPress real estate data
    • Working with the Houzez and RealHomes property systems
    • Mapping WordPress property fields to external XML structures
    • Supporting different property types and values
    • Creating feeds for multiple property portals
    • Filtering properties based on backend options
    • Excluding sold or unwanted properties
    • Supporting additional XML fields as requirements evolved
    • Correctly handling property prices
    • Including property images and videos
    • Supporting different feed URLs using the same underlying data
    • Troubleshooting XML parsing and accessibility issues
    • Scaling the feed as the number of properties increased

    The client also wanted the solution to be reusable across multiple websites rather than creating a completely different system for every website.

    Phase 1: Houzez XML Feed Development

    The relationship started when the client contacted me looking for an XML feed for the Houzez plugin.

    The first requirement was to develop a WordPress plugin capable of generating a Nestopa XML feed from the staging website.

    The client specifically asked whether the plugin could subsequently be used on multiple websites using Houzez.

    I confirmed that the plugin could be developed to work with the Houzez environment.

    The initial feed was developed and tested, including adjustments to property-type mapping.

    For example, the client changed property values such as:

    • Condo
    • House
    • Land
    • Office
    • Shop
    • Warehouse
    • Hotel
    • Building
    • Villa

    A custom mapping was then added so that the website’s Villa property type could be mapped to the required House value in the destination feed.

    This established the foundation for the later feed work.

    Phase 2: Multiple XML Feeds for HuaHinJapan.com

    After the first successful implementation, the client asked whether the same system could be adapted for HuaHinJapan.com.

    The project expanded to multiple property-network feeds.

    The feeds included:

    • Proppit
    • Nestopa
    • Listanza

    A separate URL was also created for the Proppit feed so the same feed could be accessed using another filename for a different integration requirement.

    The completed feed URLs included separate Proppit, Nestopa and Listanza endpoints.

    This demonstrated an important advantage of the approach: one WordPress property database could feed multiple external platforms through different XML formats and endpoints.

    Handling Feed Accessibility Problems

    The XML itself was functioning correctly, but the client’s technical team later reported that the Nestopa feed could not be accessed from their server because the feed appeared to be blocking bots.

    Rather than assuming the XML structure was incorrect, the issue was investigated separately as an accessibility/security problem.

    An alternative feed location was provided for testing, and the client was advised to check whether an anti-spam plugin was interfering with external access.

    This distinction between feed-generation problems and server-access problems was important when troubleshooting the integration.

    Phase 3: Filtering Property Listings

    The requirements became more sophisticated as the client’s property portfolio grew.

    For the Nestopa feed, the client requested that properties marked as Sold should be excluded.

    The feed was subsequently updated specifically for this requirement.

    Later, the client requested a Proppit feed for another website that would include properties only when a specific backend Proppit option was selected.

    A custom WordPress plugin was developed to apply that condition when generating the XML feed.

    This transformed the feed from a simple “export everything” system into a rules-based property syndication feed.

    Phase 4: Images, Prices and Property Metadata

    One of the recurring challenges with real estate XML feeds is ensuring that all important property information is transferred correctly.

    The client received feedback that some listings were being published without images because the XML did not contain the required pictures information.

    The feed was updated to include the required picture data.

    A specific property was also identified as missing the required price information, which was investigated and corrected.

    Later, a pricing issue occurred because the original rent-price field had been removed from the website.

    The feed was adapted to use the site’s “Sale or Rent Price (Only digits)” field instead, restoring the correct price information in the XML.

    Phase 5: Adding the “DeBoost” Logic

    The client later introduced a more advanced requirement for Proppit.

    They wanted properties to be promoted by default, while allowing administrators to disable promotion for individual listings.

    The requested XML behavior was:

    • Default property → <is_boosted>TRUE</is_boosted>
    • Property marked for removal/deboost → <is_boosted>FALSE</is_boosted>

    The feed was updated to derive the value from the website’s backend option.

    The implementation was based on the WordPress field:

    inspiry_remove_proppit_boost

    The client subsequently confirmed that the implementation was working correctly.

    This was an example of converting a WordPress backend workflow into XML business logic.

    Phase 6: Expanding the Feed With Additional Fields

    As the client’s XML requirements evolved, additional property information was added.

    One example was the Project Name field, which needed to appear in the Nestopa XML under the project tag.

    Another requirement was adding the property floor number.

    The client specified that the floor field should be optional and only appear when the value was available. The implementation connected the WordPress custom field inspiry_floor_level to the XML floor tag.

    The completed implementation was subsequently connected to both Proppit feed versions.

    Phase 7: Supporting Larger Property Inventories

    The number of properties eventually increased significantly.

    At one stage, the client requested a separate version of the Proppit feed containing approximately 550 properties, rather than applying the existing Proppit2 filtering rule.

    A second version of the feed was created:

    proppit_xml_feed_v2.xml

    This allowed the client to maintain different feed purposes without disrupting the original feed.

    As the property database continued to grow, pagination eventually became necessary.

    In August 2025, the client reported a critical issue with the HuaHinJapan Nestopa feed. The solution involved introducing pagination because the number of properties had increased.

    The proposed architecture was to combine the paginated results into a final static XML file periodically, allowing the receiving system to continue downloading a single feed.

    This provided a practical way to handle a growing property inventory while preserving the existing integration model.

    Phase 8: Video and Multimedia Support

    The project also evolved beyond basic property information.

    The client later requested support for YouTube videos in the Proppit XML.

    The feed was updated with a dedicated videos structure so that video URLs could be included separately from other virtual-tour information.

    The videos tag was subsequently added to both Proppit feed versions.

    This was particularly important for property syndication because multimedia information can be lost if it is not explicitly mapped into the destination XML format.

    Ongoing Troubleshooting and Maintenance

    The project continued to require occasional maintenance after the original development.

    Examples included:

    XML parsing issue

    In May 2024, the client’s development team reported an XML parser error indicating that the receiving system was not recognizing the beginning of the XML document.

    The feed was checked, and the existing Proppit feed was confirmed to be functioning from the website side.

    Feed availability issue

    In October 2024, the HuaHinJapan Nestopa feed generated an XML parsing error:

    xmlParseEntityRef: no name

    The client requested a correction, and the feed was subsequently restored so that it could be reprocessed by the receiving system.

    Property removal issue

    In January 2025, the client reported that a property whose Proppit option had been removed was still appearing in the XML feed.

    The feed was investigated and subsequently updated.

    These requests demonstrate that XML feed development is not always a one-time task. Changes to WordPress fields, property workflows, external requirements and third-party importers can require ongoing feed maintenance.

    The Technical Approach

    The overall solution evolved around several core principles:

    WordPress Property Data → Custom Mapping Logic → XML Generation → Dedicated Feed URL → External Property Platform

    The implementation included:

    • Custom WordPress plugins
    • Property-field mapping
    • Conditional property filtering
    • Property-status filtering
    • Custom XML tags
    • Image mapping
    • Price mapping
    • Video mapping
    • Backend checkbox integration
    • Multiple feed endpoints
    • Separate feed versions
    • XML troubleshooting
    • Pagination for larger inventories
    • Static feed generation for external consumption

    Rather than forcing every external platform to consume the same generic feed, individual XML structures could be adapted to the requirements of the receiving platform.

    Results

    The project grew from a single XML feed requirement into a long-running feed-development relationship covering multiple websites and property networks.

    Key outcomes documented in the project include:

    • Custom XML feed developed for a Houzez-based website
    • Reusable approach for multiple WordPress property websites
    • Proppit XML feeds
    • Nestopa XML feeds
    • Listanza XML feed
    • Multiple feed URLs for different integration requirements
    • Property-type mapping
    • Sold-property filtering
    • Proppit checkbox filtering
    • Approximately 550-property feed version
    • Image support
    • Price corrections
    • Project-name mapping
    • Floor-number mapping
    • is_boosted / DeBoost logic
    • YouTube video support
    • XML troubleshooting and maintenance
    • Pagination strategy for increasing property inventories

    Most importantly, the client repeatedly returned with new websites and new feed requirements. The conversation records show requests in 2023, 2024 and 2025, including a new Nestopa feed for Star Property and later work on the growing HuaHinJapan feed.

    Client Feedback

    The client repeatedly expressed satisfaction with the work.

    Examples include:

    “You are the best!”

    and later:

    “Ranjit, excellent work! Very happy again.”

    The client also described the XML work as “amazing” when referring to the Proppit implementation.
    These comments are particularly meaningful because they came after the initial project had evolved into ongoing technical support and increasingly complex feed requirements.

    Key Takeaways

    This project demonstrates that a real estate XML feed is more than simply converting WordPress posts into XML.

    A production property feed may need to handle:

    Data Mapping
    Different property platforms require different field names, structures and accepted values.

    Business Rules
    Only selected properties may need to be exported, while sold or deboosted properties may need different treatment.

    Multimedia
    Images, floor plans, virtual tours and YouTube videos may require dedicated XML structures.

    Data Accuracy
    Property prices and custom fields must remain synchronized with the WordPress backend.

    Scalability
    A feed that works with a small number of properties may require pagination or other optimization as the inventory grows.

    Third-Party Compatibility
    External platforms may introduce parser, accessibility or validation requirements that need investigation separately from the WordPress implementation.

    Conclusion

    What began as a small XML-feed project became a long-term technical collaboration involving multiple real estate websites, multiple property portals and numerous custom feed requirements.

    The project is a good example of how a well-designed WordPress XML feed can evolve alongside a real estate business—from a basic property export to a flexible syndication system capable of handling filtering, custom fields, multimedia, business rules and larger property inventories.

    Need a custom XML feed for your WordPress real estate website?

    I can develop custom XML, RSS or JSON feeds based on your WordPress fields, real estate plugin, API documentation and destination portal requirements.

  • Case Study 12: Building a Zillow New Construction XML Feed from WordPress

    Project Overview

    A custom home builder approached us to develop a Zillow New Construction XML feed directly from their WordPress website.

    The website was built with WordPress and the Avada theme, while the core real estate data was managed through WP Toolset custom post types, custom fields, and taxonomies.

    The primary objective was to create a structured XML feed containing communities, floor plans, and available properties, while matching as many of Zillow’s required parameters as possible.

    Client: J Thomas Homes
    Website: jthomashomes.com
    Feed Type: Zillow New Construction XML Feed
    Platform: WordPress
    Data Management: WP Toolset
    Theme: Avada
    Builder ID: 7681

    The Challenge

    The project presented several data-mapping challenges because the information required for the Zillow feed was stored across different parts of the WordPress website.

    Most of the property information was stored using WP Toolset custom fields and taxonomies, including the structured information required for communities, floor plans, and properties.

    However, the property’s photo galleries were managed separately through the Avada theme’s gallery functionality.

    This meant that a successful solution needed to combine information from multiple WordPress data sources into a single Zillow-compatible XML structure.

    The client specifically highlighted that the photo galleries were essential because the images also needed to be submitted to Zillow.

    The existing website also had WP All Export Pro installed and being used for another business. An existing implementation had successfully handled the integration of photo galleries, providing a useful reference for the required approach.

    Project Requirements

    The client requested a feed capable of representing:

    • New construction communities
    • Single-family floor plans
    • Townhome floor plans
    • Available properties
    • Property and floor-plan information
    • Images from Avada photo galleries
    • Data stored in WP Toolset custom fields
    • Data stored in WP Toolset taxonomies
    • Zillow-specific parameters and identifiers
    • Lead-routing information

    The goal was to match as many of Zillow’s available parameters as possible while maintaining the existing WordPress setup.

    Community Selection

    During development, the client specified that only five communities should initially be included in the XML feed:

    1. Ogden Towns
    2. Nibley Meadows
    3. Presidents Park
    4. Springville Towns
    5. West Fields

    This allowed the feed to be focused on the specific communities required for the initial Zillow submission.

    Zillow Builder Identification

    Another important requirement was obtaining the correct Zillow identifier.

    The client initially indicated that they were waiting for the account information from Zillow. Zillow subsequently provided the unique Builder ID 7681, which was then used for the feed configuration.

    Using the correct builder identifier is important when submitting a builder’s inventory to a third-party real estate portal because it connects the feed data with the appropriate builder account.

    Data Integration Approach

    The key technical challenge was bringing together data stored through different WordPress systems.

    The implementation needed to work with:

    WP Toolset

    • Custom post types
    • Custom fields
    • Taxonomies
    • Community information
    • Floor-plan information
    • Property information

    Avada

    • Photo galleries
    • Property images

    The resulting feed needed to transform this WordPress data into the XML structure expected by Zillow.

    Rather than requiring the client to restructure their existing website, the feed was designed around the data already maintained within WordPress.

    This approach reduced the need for duplicate data entry and allowed the website to remain the primary source of property information.

    Photo Gallery Integration

    One of the more complex parts of the project was handling images.

    The majority of the XML information could be obtained from WP Toolset, but the images were maintained through Avada’s photo gallery system.

    Therefore, the feed generation process needed to retrieve the appropriate gallery images and associate them with the corresponding communities, floor plans, or properties.

    The existing WP All Export Pro implementation on the website demonstrated that the gallery data could be integrated successfully, which provided a useful reference when developing the new feed.

    Lead Routing

    The Zillow feed also required lead-routing information.

    The client was asked to provide an email address where Zillow leads should be delivered. They indicated that if only one email address was supported, leads should be routed to their primary email, while if two addresses were supported, a second address could also be included.

    This ensured that the feed was not limited to property data alone but also incorporated the contact information required for lead handling.

    Result

    After the feed was prepared, the client submitted the XML to Zillow for review.

    On June 3, 2025, the client confirmed that the feed had been submitted to Zillow and that Zillow’s support team was reviewing it to ensure everything was correct.

    The project demonstrated how a WordPress-based real estate website can be connected to a major property portal even when the required information is distributed across:

    • Custom post types
    • Custom fields
    • Taxonomies
    • Theme-managed galleries
    • Existing WordPress export configurations

    Key Takeaways

    1. WordPress can serve as the central data source

    A real estate website does not necessarily need a separate database or property management platform to generate a portal feed. Structured WordPress data can be transformed into a portal-specific XML format.

    2. Custom fields require careful mapping

    Real estate websites frequently store information in custom fields and taxonomies. Each field must be mapped appropriately to the destination portal’s XML requirements.

    3. Images can add another layer of complexity

    When images are managed separately from the primary property data, the feed-generation process needs to combine both sources correctly.

    4. Existing integrations can provide valuable references

    The existing WP All Export Pro configuration provided useful insight into how the website’s Avada galleries were being handled, helping inform the new feed implementation.

    5. Portal-specific requirements matter

    A successful XML feed is not simply an export of WordPress content. It needs to follow the destination portal’s expected structure, identifiers, fields, and submission requirements.

    Conclusion

    This project involved developing a Zillow New Construction XML feed for a WordPress-based home builder website, combining structured WP Toolset data with Avada-managed photo galleries.

    The final solution was prepared around the client’s existing WordPress architecture and included the required communities, builder identification, property information, images, and lead-routing details.

    The completed XML was then submitted to Zillow for review, providing the client with a portal-ready feed for their new construction inventory.

    Need a custom XML feed for Zillow, Realtor portals, real estate marketplaces, or another property platform?

    We can develop custom WordPress XML/RSS feeds that map your existing custom fields, taxonomies, property data, and images into the format required by your target portal.

  • Case Study 11: Google Shopping XML Feed for WordPress Custom Fields: Whitewater Tours Case Study

    Project Overview

    A client from Whitewater Tours needed a Google Shopping XML product feed for approximately 50 products on their WordPress website.

    The website used custom WordPress fields to store product information, and the client wanted that information converted into an XML feed that could be used with Google.

    The project was a good example of how a custom XML feed can be built around an existing WordPress data structure rather than requiring the client to manually maintain a separate product feed.

    Project Requirements

    The main requirements were:

    • Create a Google Shopping XML product feed.
    • Generate the feed from WordPress custom fields.
    • Support approximately 50 products.
    • Make the feed accessible through a dedicated XML URL.
    • Ensure newly added products could automatically appear in the feed.
    • Provide a solution suitable for submission to Google Merchant Center.

    The initial project budget was $50, with a three-day delivery requirement.

    Understanding the Client’s WordPress Structure

    The client explained that the products were already managed through WordPress and that the required information was stored in custom fields.

    Instead of creating a completely separate product database, the approach was to work with the existing WordPress content and transform the available product information into the required XML feed structure.

    This is an important consideration when developing feeds for WordPress websites.

    A feed should ideally work with the website’s existing data rather than forcing the site owner to maintain product information in multiple places.

    Creating the Custom XML Feed

    A custom WordPress XML feed solution was developed specifically for the website.

    The feed was designed to collect the relevant product information from WordPress and make it available through an XML endpoint.

    The resulting feed was intended to provide a direct URL that could be supplied to Google Merchant Center.

    The client also asked whether the feed would automatically include a new product when it was added to the website.

    The answer was yes.

    This meant the client would not need to manually recreate the XML feed every time a new product was published.

    WordPress Plugin Installation

    Because the website was running as a WordPress multisite, the plugin installation required some additional coordination.

    Initially, the required permissions were not available for installing the plugin directly.

    The client therefore uploaded the provided plugin package, after which the feed could be tested and refined.

    This is a common practical issue when working on client websites: the technical implementation may be straightforward, but access permissions and hosting configuration can affect the development workflow.

    Testing and Refinement

    The plugin was not considered finished immediately after installation.

    The client asked whether the work was complete once the plugin had been uploaded.

    The response was that the feed still needed to be checked and refined before being considered final.

    The goal was to make sure that the generated XML could be used as the feed source and that the client could subsequently submit the feed URL to Google Merchant Center.

    The client also confirmed that they would test the implementation and report any issues.

    Automatic Product Updates

    One of the useful features of the implementation was that the XML feed was connected to the site’s WordPress product data.

    The client specifically asked:

    If a new product is added, will it auto go to the XML feed?

    The answer was yes.

    This makes a custom feed considerably more useful for an active website because the feed can continue to reflect the site’s product catalog without requiring the site owner to manually edit an XML file every time a product is added.

    Expanding Beyond Google Shopping

    After the initial XML feed work, the client asked about another Google integration: Google Things to Do.

    This introduced a different type of feed requirement involving event and activity information.

    The discussion moved toward JSON feeds and customized data for individual events.

    The client was informed that the data structure on the website would need to be customized for each event and that the work could be started with a single event to verify the output before expanding the implementation.

    This demonstrated another advantage of working with custom feed development: once the underlying WordPress data and feed requirements are understood, similar structured-data integrations can be evaluated and developed around the same website.

    A Later Check: Feed Endpoint No Longer Available

    More than a year after the original implementation, the old Google feed URL was checked again:

    whitewatertours.com/google.xml

    The endpoint is currently returning a Page Not Found response.

    This does not necessarily mean that the original feed implementation failed. Websites are frequently redesigned, plugins are removed, URLs are changed, or WordPress configurations are modified over time.

    Because the current endpoint is no longer available, the next step is to determine whether the client still requires the Google Shopping feed and, if so, what has changed on the website since the original implementation.

    A follow-up was therefore sent to the client offering to investigate the issue and restore the feed if it is still required.

    Key Takeaways

    This project highlights several important considerations when creating custom XML feeds for WordPress websites.

    1. Work With Existing WordPress Data

    Using the website’s existing custom fields can eliminate unnecessary duplication and allow the feed to stay connected to the site’s product information.

    2. Automate Feed Updates

    Automatically generating the XML output means that new products can be incorporated into the feed without manually editing an XML file.

    3. Consider WordPress Multisite During Development

    Multisite installations can introduce additional permission and plugin-installation considerations that should be accounted for before development begins.

    4. Test Before Submitting the Feed

    A feed should be checked and refined before its URL is submitted to Google Merchant Center.

    5. Feed Maintenance Matters

    Even a working feed can become unavailable later because of website changes, plugin removal, URL changes, migrations, or other configuration changes.

    For this reason, an XML feed should be treated as part of the website’s ongoing technical infrastructure rather than a completely one-time task.

    Conclusion

    The Whitewater Tours project started with a straightforward requirement: convert approximately 50 WordPress products stored using custom fields into a Google Shopping XML feed.

    A custom WordPress feed solution was developed, installed on the client’s multisite environment, and prepared for testing and use with Google Merchant Center.

    The project also opened the door to discussing additional structured-data integrations such as Google Things to Do.

    The later discovery that the original /google.xml endpoint is no longer available also illustrates an important aspect of feed development: ongoing website changes can affect previously working integrations.

    For businesses relying on XML feeds for Google or third-party platforms, periodic testing of the feed URL is therefore a useful part of website maintenance.

  • Case Study 10: Building and Maintaining a Multi-Portal Real Estate Feed System for WordPress

    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:

    1. Property ID prefixes.
    2. Minimum sale price.
    3. Minimum rental price.
    4. Custom fields.
    5. Specific properties to include.
    6. Specific properties to exclude.
    7. Property status.
    8. 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.

  • Case Study 9: Building and Optimizing RSS Mashups Across 52 WordPress Websites

    Introduction

    Managing content across dozens of WordPress websites can create a significant challenge when the goal is to aggregate the latest articles into centralized RSS feeds.

    In this project, the client was managing a network of 52 WordPress websites where articles were published using WordPress Pages rather than the traditional Posts system. The requirement was to create multiple RSS mashups, with each mashup combining content from a selected group of websites into a single feed.

    The project eventually evolved beyond simple RSS aggregation to include responsive widgets, featured images, publication names, scheduled feed updates, performance optimization, duplicate-story handling, and larger content archives.

    The Initial Requirement

    The client initially wanted six RSS mashups, with each feed aggregating approximately 13 websites. Whenever one of the websites published a new article, it needed to appear automatically in the appropriate RSS mashup.

    A key technical consideration was that these websites were publishing articles through Pages instead of Posts. This meant the solution needed to work with the client’s existing publishing structure rather than assuming a conventional WordPress blog setup.

    The first mashup was eventually defined around seven websites:

    • Tarragindi News
    • Forest Lake News
    • Holland Park News
    • Sunnybank Hills News
    • Moorooka News
    • Annerley News
    • Robertson News

    The first implementation was offered as a custom WordPress plugin capable of generating an RSS mashup from those websites.

    Adding a Front-End RSS Widget

    The client did not only want an RSS feed URL. They also wanted the aggregated stories to appear directly on their websites.

    The requirement was for a widget that could display headlines from multiple publications, with the publication name shown alongside or below each story.

    The widget was therefore developed alongside the RSS mashup. The implementation was also designed to be responsive, allowing it to adapt to different device sizes.

    An option was also added to control the number of stories displayed. This allowed the client to use different limits depending on where the widget was placed—for example, displaying the latest 10 stories in one location and more stories elsewhere.

    The completed widget was subsequently installed across the seven websites in the first mashup.

    Expanding the RSS Network

    After successfully implementing the first mashup, the project expanded.

    The client began requesting additional mashups containing different numbers of websites. A pricing model based on the number of websites in each mashup was established, making it possible to scale the solution across the client’s growing network.

    The project eventually included multiple groups of websites, with separate custom plugins used for different mashups.

    This demonstrated an important advantage of the approach: rather than manually copying articles between websites, each WordPress installation could continue publishing independently while the mashup system aggregated the content automatically.

    Adding Featured Images

    As the RSS mashups became more useful, the client wanted the feeds to contain richer content.

    One requested improvement was the ability to include the featured image thumbnail associated with each article, together with the publication URL.

    The requirement was confirmed as technically possible, allowing the mashups to provide more than just text headlines.

    This made the aggregated content more suitable for visual widgets and homepage displays.

    A Separate Centralized Graphic Widget

    The project also introduced another interesting requirement.

    The client wanted a widget that could display a graphic or GIF across multiple WordPress websites. Instead of uploading the same graphic separately to every website, the idea was to maintain the graphic at a central location and have the embedded widgets display it across the network.

    The proposed approach was to use a fixed image location and consistent filename, allowing the same embedded widget to display the updated image across multiple websites.

    Although the client later found a workaround for this particular requirement, the discussion showed how the RSS project was evolving into a broader content-distribution system.

    Performance Problem: Excessive Requests

    As more mashups and websites were added, a performance issue eventually appeared.

    In May 2024, the client reported that the plugins were generating a large number of requests, sometimes more than one request per second, resulting in increased CPU usage on the server.

    This was an important turning point in the project.

    The original approach was checking for new content very frequently. While frequent checking can make feeds appear more up to date, it can become inefficient when multiple websites and mashups are involved.

    The client suggested reducing the checking frequency to approximately once per hour.

    The plugins were subsequently updated so that the feed refresh frequency was reduced, helping minimize unnecessary server requests.

    Updates were supplied for multiple groups of websites, including seven-site, five-site, six-site, and ten-site installations.

    Solving a “Too Many Requests” Feed Problem

    The performance improvements became particularly relevant when one of the mashup feeds later developed problems.

    In May 2025, the client reported that the West Brisbane News Feed had broken links, while another feed was displaying errors.

    After investigation, the West Brisbane issue was identified as being related to “Too many requests.” The feed was changed to update approximately once per hour instead of making requests continuously.

    A temporary alternative feed was also provided while the updated system took effect.

    The plugin was then further optimized to reduce server load.

    This part of the project highlighted an important lesson in feed development:

    A feed aggregator needs to balance freshness with server efficiency.

    Checking for new content every second is usually unnecessary for news aggregation and can create significant server load when the system scales across many websites.

    Scaling to Larger Mashups

    By 2025, the client was requesting even larger mashups.

    New requirements included mashups combining 10 and 13 websites, while the client also had potential future mashups containing 16 and 26 websites.

    The project had therefore grown considerably from its original seven-site RSS feed.

    The client also wanted to retain the established format, including:

    • A defined number of stories
    • Publication name instead of author name
    • Hourly refresh
    • Potentially displaying story dates
    • Installation across multiple WordPress websites

    This required the RSS mashup system to remain flexible as the number of source websites increased.

    Handling Duplicate Stories

    Another challenge appeared as the client began publishing some stories across multiple publications.

    Because the same article could appear on several websites, the RSS mashup could potentially display what appeared to be duplicate stories.

    In July 2025, the client asked whether the system could be improved so that only one version of an article would appear in the mashup when the same story had been published across multiple sites.

    A title-based comparison approach was proposed for identifying duplicates.

    The updated plugin would be installed across the WordPress websites participating in the mashup.

    This represented another step forward—from simply aggregating content to intelligently controlling how aggregated content was presented.

    Improving Mobile Presentation

    The client also wanted the RSS widget to look better on the homepage, particularly on mobile devices.

    The proposed improvement involved responsive CSS so that images could occupy the full available width on mobile screens.

    This was important because the same RSS content was being displayed in different layouts and devices.

    The project therefore required consideration of both:

    • Backend feed generation
    • Frontend content presentation

    Archive and Content Volume Requirements

    As the amount of aggregated content increased, the client wanted to use the mashup as an archive as well as a live news display.

    In July 2025, the client asked whether pagination could be added to the archive. When pagination was determined not to be possible within the existing setup, the alternative was to increase the number of displayed items for the main homepage while retaining a smaller number for the sidebar.

    The number of displayed items was subsequently increased.

    This was another example of adapting the implementation to the practical requirements of the existing WordPress environment rather than rebuilding the entire system.

    Project Evolution

    What started as a request for six RSS mashups eventually became a long-term WordPress feed development and maintenance project.

    The major stages included:

    1. Initial RSS mashup development
    2. Aggregation of WordPress Pages from multiple websites
    3. Responsive RSS widgets
    4. Configurable article limits
    5. Featured image support
    6. Multiple independent mashups
    7. Feed refresh optimization
    8. CPU/server-load reduction
    9. Troubleshooting “Too many requests” issues
    10. Larger 10-, 13-, 16- and 26-site mashups
    11. Duplicate-story detection
    12. Mobile layout improvements
    13. Larger content displays for archive-style usage

    Key Technical Lessons

    1. Aggregation becomes more complex as the network grows

    A feed that works well with a few websites can behave very differently when dozens of websites are involved.

    Request frequency, caching, server resources and feed size become increasingly important.

    2. Real-time does not always mean every-second polling

    For a news aggregation system, hourly updates may provide an appropriate balance between freshness and server performance. In this project, excessive request frequency eventually contributed to CPU and “Too many requests” problems.

    3. RSS feeds can become part of the website’s front-end

    The project demonstrated that RSS does not have to be used only as a backend data format. The aggregated feed can also power custom widgets and homepage content displays.

    4. Duplicate content needs to be considered

    When the same publisher operates multiple websites, the same story may legitimately appear on several domains. A title-based comparison can help reduce repeated stories within an aggregated feed.

    5. Mobile presentation matters

    An RSS feed may technically work while its visual presentation remains poor. Responsive CSS and appropriate image sizing can significantly improve how aggregated content appears on phones and other devices.

    Conclusion

    This case demonstrates how a relatively simple RSS requirement can evolve into a sophisticated multi-site content aggregation system.

    The original requirement was to combine articles from a network of WordPress websites into several RSS mashups. Over time, the system expanded to support widgets, images, configurable story limits, larger website groups, scheduled updates, performance optimization, duplicate detection and improved mobile presentation.

    The most valuable aspect of the project was not simply creating an RSS feed—it was continuously adapting the feed infrastructure as the client’s network, publishing strategy and technical requirements changed.

    For organizations managing multiple WordPress websites, a custom RSS/XML aggregation solution can provide a practical way to centralize content while allowing each individual publication to continue operating independently.

  • Case Study 8: Automating an XML, Excel, and SFTP Data Workflow

    From Manual XML Conversion to a More Efficient SFTP-Based Workflow

    Project Overview

    A client approached me with a requirement to convert an XML file into Excel and then convert the updated Excel data back into XML.

    The initial requirement was relatively straightforward: create two scripts that would allow the client to upload an XML file, generate an Excel file from it, make changes in Excel, and then generate an updated XML file.

    As the project progressed, however, the client’s workflow became more sophisticated. The XML files were being exchanged through an SFTP server, and the client wanted to reduce the amount of manual work involved in moving, editing, converting, and returning those files.

    This turned the project from a simple XML conversion task into a broader XML/Excel/SFTP workflow automation project.

    The Initial Requirement

    The client first contacted me looking for a way to convert XML data into Excel and then convert the modified Excel file back into XML.

    The proposed solution consisted of two scripts:

    1. XML → Excel
    2. Excel → XML

    The client had web hosting available, so the initial plan was to install the scripts online and provide separate links for the conversion process.

    The basic workflow was designed to be simple for the end user:

    Upload XML → Download Excel → Edit Excel → Upload Excel → Download XML

    The client initially considered whether a web interface could eliminate the need for Excel, but based on the workflow at that stage, using Excel was considered more user-friendly and practical.

    The Workflow Became More Complex

    Several months later, the client returned because the original converter was working well, but they wanted to improve the overall process.

    The client explained that the actual workflow involved:

    • XML files being pulled from an SFTP server
    • XML being converted into Excel
    • New information being added or existing information being updated in Excel
    • Excel being converted back into XML
    • The resulting XML being uploaded back to the SFTP server

    The goal was to make this entire process smoother and more automated.

    This was an important change in scope because the challenge was no longer just XML conversion. The system now had to fit into an existing SFTP-based business workflow.

    Designing the Automation Workflow

    The client proposed using a dedicated machine onsite that could remain running continuously.

    The proposed workflow was roughly:

    SFTP Server
    ↓
    Retrieve XML
    ↓
    Convert XML to Excel
    ↓
    Place Excel in Shared/Local Folder
    ↓
    Client Updates Excel
    ↓
    Move Updated Excel to Completed Folder
    ↓
    Convert Excel Back to XML
    ↓
    Upload XML to SFTP

    The client also considered using watched or “hot” folders so that files could automatically move through the workflow once users completed their changes.

    This approach provided a practical way to connect the remote SFTP process with the client’s local network and Excel-based workflow.

    Working Around SFTP Restrictions

    One of the technical considerations was that the SFTP server was restricted to an IP address associated with the client’s site.

    Because of this restriction, the automation could not simply be deployed and connected to the SFTP server from an arbitrary hosting environment.

    The client explained that the SFTP access was locked to the client’s IP, which meant the processing component would need to run on a remote or onsite system that had the appropriate network access.

    The solution therefore needed to separate the conversion logic from the final onsite environment.

    The plan was to develop the processing script so that it could be tested and then run on the client’s remote system.

    Development and Delivery

    After the client received approval to move forward, the automation project was started.

    The client specifically confirmed approval to proceed, and I began working on the requested automation.

    The delivered solution was intended to support the client’s XML/Excel processing workflow while allowing the final SFTP and local-network components to be configured within their own environment.

    After delivery, the client continued working on the onsite portion of the workflow. They explained that they would have a dedicated computer onsite and could provide remote access so that the remaining workflow could be completed.

    The Result

    The project evolved through several stages:

    Stage 1 — XML Conversion

    The original requirement was to provide a practical way to convert XML data into Excel and back into XML.

    Stage 2 — Hosted Conversion Tools

    The conversion scripts were planned for installation on the client’s hosting environment, giving the user simple upload/download functionality.

    Stage 3 — SFTP Integration

    The client’s real-world workflow introduced SFTP as the source and destination for the XML files.

    Stage 4 — Local Processing

    Because of the SFTP IP restrictions, the workflow needed to operate within the client’s network environment.

    Stage 5 — Workflow Automation

    The client explored using a dedicated onsite machine and watched folders to reduce manual file handling.

    This progression demonstrates how a relatively simple data-conversion requirement can evolve into a customized business automation workflow once the complete operational process is understood.

    Key Technical Challenges

    The project involved more than simply converting between two file formats.

    The main challenges included:

    • Maintaining the XML-to-Excel conversion workflow
    • Converting modified Excel data back into the required XML structure
    • Working with an SFTP-based data exchange process
    • Handling an SFTP server restricted by IP address
    • Designing a workflow suitable for a dedicated Windows machine
    • Connecting local folders with the conversion process
    • Considering automated file monitoring and processing
    • Keeping the process simple enough for the end user

    The project also required coordination between the conversion software, the client’s hosting/network environment, SFTP access, and the local workflow.

    Why Workflow Design Matters

    One of the most important lessons from this project was that solving the immediate technical problem is only part of the job.

    The first requirement was essentially:

    “Convert XML to Excel and Excel back to XML.”

    But the client’s actual business process was closer to:

    SFTP → XML → Excel → User Updates → Excel → XML → SFTP

    Once the complete workflow was understood, the solution could be designed around the client’s actual operation rather than treating XML conversion as an isolated task.

    This is often the difference between a basic utility script and a solution that fits into a real business process.

    Conclusion

    What started as an XML-to-Excel conversion project developed into a broader SFTP and workflow automation project.

    The client initially needed a straightforward conversion tool, but after using the converter, they returned with a larger requirement to make their XML update process more efficient and automated. The client specifically reported that the converter “works great” before discussing the next stage of automation.

    The project is a good example of how understanding the complete data flow can reveal opportunities for automation beyond the original request.

    For businesses that regularly exchange structured XML data through SFTP while relying on Excel for manual updates, a customized conversion and automation workflow can significantly simplify the process and reduce repetitive file-handling steps.

  • Case Study 7: Building and Maintaining Custom RSS Feeds for Yahoo, MSN and Multi-Site Content Syndication

    Introduction

    Content syndication can be deceptively complex. A WordPress website may have a perfectly valid RSS feed, yet that feed may not work correctly with a major publishing or syndication platform because of differences in formatting, links, dates, embedded media, content length, caching, or platform-specific requirements.

    This case study follows a long-term RSS feed development and maintenance project for a publisher operating multiple automotive and news websites. What began as a request to customize an existing RSS feed eventually developed into an ongoing technical partnership covering Yahoo and MSN-compatible feeds, multiple websites, media handling, feed filtering, troubleshooting, and WordPress maintenance.

    The project demonstrates why a successful syndication feed requires more than simply generating valid XML.

    The Initial Requirement

    The first conversation began in December 2022 when the client asked about creating an RSS feed for The Auto Wire, along with unique feeds for Yahoo and MSN.

    The website already had a standard WordPress RSS feed:

    https://theautowire.com/feed

    The first step was therefore not to create an entirely new system unnecessarily, but to understand the existing feed and determine what format the syndication partners required.

    The project became active again in August 2023 when the client supplied Yahoo’s technical guidelines for article ingestion and explained that many articles were not being pulled correctly from the site’s news section.

    A custom WordPress feed update was then commissioned.

    Adapting the Existing RSS Feed to Yahoo’s Requirements

    The initial task was relatively small: modify the existing RSS feed according to Yahoo’s technical specifications.

    The custom implementation was offered as an RSS/XML feed project, with the objective of updating the existing feed rather than replacing it unnecessarily.

    However, once Yahoo began ingesting the content, several practical issues appeared.

    The client reported that some articles were appearing as block text and that article links were missing. Importantly, the client preferred not to submit an entirely new feed because doing so could potentially introduce another approval delay.

    The solution was to modify the original feed so that it contained properly formatted content and links while retaining the existing feed URL.

    This was an important lesson from the project:

    When a syndication feed is already approved or being processed, improving the existing feed can sometimes be preferable to replacing it with a completely new feed.

    Correcting Publication Dates

    Another problem appeared with article timestamps.

    The client noticed that an article published on the website that day was appearing in Yahoo as though it had been published two days earlier.

    Investigation revealed that the feed was using the post-modified date rather than the original publication date.

    The feed was updated to use the post publish date, which aligned the syndication information more closely with when the article was actually published.

    For news websites, this distinction is particularly important because syndication platforms may use timestamps to determine article freshness and ordering.

    Handling Embedded Videos and Tweets

    The next challenge involved embedded media.

    The client noticed that embedded videos and tweets were appearing as raw URLs on Yahoo instead of being rendered as intended. The concern was that the site’s embedded content was being corrupted or transformed during RSS generation.

    The feed was subsequently updated to preserve the content being supplied to the syndication platform, and the client was asked to allow the syndication system to perform another fetch.

    This illustrates another important point about RSS development:

    A feed is not simply a text export of a webpage.

    HTML, JavaScript-generated embeds, video players, social posts, images and other media can behave very differently when consumed by an external platform.

    Expanding the Solution to a Second Website

    The successful work on The Auto Wire led to another project.

    In September 2023, the client requested a new feed for Backfire News, following the same Yahoo technical guidelines.

    A custom WordPress plugin/feed implementation was developed for the second site.

    The client later confirmed that the syndication feed had been published on Yahoo and that everything looked good, with only a small wording adjustment required in the “Read the full story” section.

    At this stage, the project had evolved from a one-off RSS customization into a reusable approach for multiple publishing websites.

    Troubleshooting Feed Links

    In November 2023, a major feed issue appeared.

    The client reported that links in the RSS feed were pointing to images rather than the actual articles. The problem affected syndicated content and required immediate investigation.

    After checking the feed, the links were confirmed to be functioning correctly again.

    This type of issue demonstrates why feed troubleshooting should include testing the actual generated XML and destination URLs, rather than relying solely on how the WordPress page appears in a browser.

    Adding Newsletter and Social Media Information

    In February 2024, the client requested another enhancement.

    The RSS feeds needed a standard footer containing newsletter and social media information. The requirement applied to both The Auto Wire and Backfire News, with different wording and links for each website.

    The implementation was extended so social links could be added to the bottom of syndicated content, alongside the existing “Read the full story” information.

    The same approach was subsequently applied to a new website, Modern Car Collector, which also required a feed based on updated Yahoo article-ingestion guidelines.

    Supporting a Third Website

    Modern Car Collector became the third site in the feed ecosystem.

    After the feed was delivered, the client submitted it to the syndication partner for review. A temporary site-access issue was also reported during the process, and the website was checked from another environment.

    The client then requested social links to be added to the new feed, including Facebook and Twitter. These were added shortly afterward.

    The same type of customization was then applied to The Auto Wire’s feed with its own newsletter and social wording.

    Diagnosing Delayed Feed Ingestion

    One of the more technically interesting problems appeared in February 2024.

    The client reported that posts from Modern Car Collector and Backfire News were not appearing in the RSS feeds immediately after publication. The feeds were also being checked using evaluation tools associated with the syndication process.

    Initially, the issue was investigated from the feed and WordPress side. Time-zone settings were checked and confirmed to be correct.

    Further investigation led to caching being considered as a potential source of delay. The client was asked to provide hosting access or contact the hosting provider to disable caching for the feed URL. Changes were then applied to the feeds.

    This was a valuable distinction:

    When a WordPress post is published but an external feed still shows old content, the problem may not be the feed-generation code itself.

    Caching at the WordPress, plugin, server, CDN, or hosting level can cause an otherwise correctly generated feed to appear stale.

    MSN Feed Development and YouTube Content

    Later in 2024, the project expanded beyond article RSS feeds.

    The client wanted a feed for The Auto Wire’s YouTube videos that could work with MSN’s media requirements. The client supplied detailed Media RSS specifications describing how images, videos and other media should be represented using elements such as media:content and media:group.
    This introduced a different technical problem from traditional article RSS generation.

    The feed now needed to deal with:

    • YouTube content
    • Video metadata
    • Media RSS elements
    • External API access
    • Syndication requirements
    • Content validation

    Solving YouTube API Quota Problems

    Soon after implementation, a video failed to populate in the feed.

    Investigation identified the cause as YouTube API quota limits being exceeded. A new API key was created and monitoring was put in place.

    This was an important reminder that integrations with external APIs introduce dependencies outside the WordPress code itself.

    Even when the feed-generation logic is functioning correctly, an API quota, authentication problem, rate limit or external service failure can prevent new content from entering the feed.

    Meeting Minimum Content-Length Requirements

    Another MSN-related issue appeared when the syndication system rejected content because articles needed to contain at least 450 characters.

    The plugin was updated to handle the requirement, and subsequent testing showed that feed items contained substantially more content.

    However, the client later noticed that only part of the description appeared in the syndicated result.

    The feed was adjusted so the full description could be provided, and subsequent MSN examples showed the video content being displayed successfully.

    This part of the project demonstrates the iterative nature of syndication development:

    1. Generate the feed.
    2. Validate the XML.
    3. Submit it to the syndication platform.
    4. Observe how the platform interprets it.
    5. Identify validation or rendering issues.
    6. Adjust the feed.
    7. Test again.

    Creating a Separate Feed for MSN

    In January 2025, the client reported that The Auto Wire’s existing feed worked well with Yahoo but had issues with MSN.

    Instead of changing the existing Yahoo feed and potentially affecting its behavior, the client asked for a duplicate feed specifically for MSN.

    During investigation, an image-related problem was identified in one of the posts. The image filename needed correction, but the WordPress post could not be saved because of a permissions/security restriction.

    A separate feed was subsequently commissioned.

    This approach provided an important architectural advantage:

    One website can have different feeds for different syndication partners.

    Instead of forcing Yahoo and MSN to consume exactly the same output, separate feeds can be tailored to the technical requirements of each platform.

    Adding Per-Post Feed Filtering

    The client later requested more control over which articles appeared in the new MSN feed.

    The requirement was specific:

    • Certain posts should be excluded from the new feed.
    • Those same posts should remain available in the original RSS feed.
    • The site editor needed an easy way to control this from WordPress.

    The solution was to add a checkbox option to individual WordPress posts.

    This transformed the feed from a purely automatic system into a system with editorial control.

    Instead of manually editing XML or deleting posts, the publisher could decide which content belonged in the specialized feed while leaving the main RSS feed untouched.

    Handling YouTube Embeds in MSN Feeds

    Another issue involved YouTube videos appearing as raw URLs in syndicated content.

    The client reported that MSN’s moderation tool was detecting the video URLs rather than receiving the expected embedded video representation.

    Investigation showed that the webpage’s iframe was being generated after page load using JavaScript, meaning the iframe was not necessarily present in the raw content available to the RSS generator.

    A proposed solution was to detect YouTube URLs and generate iframe markup directly in the RSS feed.

    The client temporarily paused that change while clarifying the syndication partner’s requirements.

    This highlighted an important technical concept:

    What a browser renders is not necessarily what an RSS parser receives.

    A JavaScript-generated embed may look perfect on the website while appearing only as a plain URL to an external feed consumer.

    WordPress and Server-Level Troubleshooting

    The relationship also expanded beyond RSS development.

    In March 2025, the client encountered a PHP warning related to the RSS plugin and subsequently received a 500 Internal Server Error.

    The issue appeared to involve the hosting/server environment rather than simply the feed output.

    The client provided hosting access for investigation. By the time access was obtained, the website was functioning again, and the issue was considered consistent with a temporary server update/glitch.

    This is another common reality of long-term WordPress projects: once a custom plugin becomes critical to a publishing workflow, maintenance may include troubleshooting the interaction between WordPress, PHP, plugins, hosting and server updates.

    Further Feed Customization

    In August 2025, the client returned with another request affecting all three RSS feeds.

    This time, Yahoo needed the “Read the full story on…” text removed. A single customization was applied across the three feeds.

    By this point, the project had developed into an ongoing maintenance relationship rather than a one-time feed-generation job.

    What Made This Project Challenging?

    The technical challenge was not simply generating XML.

    The project involved multiple layers:

    1. WordPress content extraction

    The system had to correctly identify posts, publication dates, descriptions, links and media from WordPress.

    2. Custom XML/RSS formatting

    The standard WordPress RSS structure was insufficient for the requirements of external syndication platforms.

    3. Platform-specific requirements

    Yahoo and MSN had different expectations regarding article content, media, formatting and validation.

    4. External APIs

    The YouTube integration introduced API quotas and external-service dependencies.

    5. Media handling

    Images, videos, iframes, social embeds and raw URLs required special consideration.

    6. Caching

    Feed caching could cause delays between publication and syndication.

    7. Editorial control

    The publisher eventually needed the ability to exclude individual articles from one feed while keeping them in another.

    8. Hosting and server issues

    Some problems occurred outside the feed-generation logic and required investigation at the WordPress or hosting level.

    The Result

    Over the course of the project, the work expanded from one RSS feed to a multi-site syndication system supporting several publishing properties.

    The work included:

    • Custom Yahoo-compatible RSS feeds
    • MSN-specific RSS feed development
    • Multiple website feeds
    • Publication-date corrections
    • Formatted article content
    • Article links
    • Newsletter and social media footers
    • Media RSS requirements
    • YouTube video feed integration
    • API quota troubleshooting
    • Content-length validation
    • Full-description handling
    • Separate feeds for different syndication partners
    • Per-post feed exclusion controls
    • Video/embed troubleshooting
    • Feed caching investigation
    • WordPress/PHP troubleshooting
    • Ongoing feed maintenance

    The client repeatedly returned with new requirements and additional websites, eventually describing the work as part of a broader need for WordPress assistance across the sites.

    Key Lessons from the Project

    A valid RSS feed is not necessarily a syndication-ready RSS feed.

    XML can be technically valid while still failing the requirements of a specific publishing platform.

    Preserve existing feeds when appropriate.

    If a feed is already being used or approved by a syndication partner, modifying the existing feed can sometimes be safer than replacing it.

    Always test real-world ingestion.

    A feed can look correct in an XML viewer while the receiving platform interprets its content differently.

    Publication dates matter.

    Using the wrong WordPress date field can make newly published articles appear old to a syndication platform.

    External dependencies need monitoring.

    YouTube API quotas demonstrated that feed reliability can depend on services outside WordPress.

    Separate feeds can solve conflicting requirements.

    Yahoo and MSN did not necessarily need identical output. Dedicated feeds allowed the same website to provide different content structures for different partners.

    Editorial controls can make automated feeds more practical.

    A simple per-post checkbox gave the publisher control without requiring manual XML editing.

    Feed maintenance is an ongoing process.

    Syndication platforms change requirements, websites change, plugins change, hosting environments change, and content formats evolve. A feed that works today may require adjustments later.

    Conclusion

    This project began with a simple request to customize an existing WordPress RSS feed but evolved into a multi-year feed development and maintenance relationship.

    The biggest takeaway is that RSS feed development for professional content syndication is an integration problem, not merely an XML-generation problem.

    A reliable solution must consider WordPress data, XML structure, publication dates, links, media, APIs, caching, validation tools, syndication requirements and the way external platforms actually consume the feed.

    For publishers relying on Yahoo, MSN or other content-distribution platforms, having a properly engineered and maintainable feed can be just as important as having a well-functioning website.

  • Case Study 6: Fixing a Kiyoh XML Review Feed After a PHP 8.3 Upgrade

    From Custom XML Feed to Production Review Integration

    A WordPress XML/RSS project can sometimes evolve far beyond the original requirement. This case started with a relatively simple RSS feed problem and eventually became a custom XML integration for displaying Kiyoh customer reviews on a WordPress website.

    The project involved multiple websites, custom XML processing, a WordPress plugin, external review data, and eventually a compatibility issue following a PHP 8.3 upgrade.

    The Initial RSS Feed Problem

    The project originally started in May 2024 when the client needed help creating an RSS feed for jonglogistiek.nl.

    The client had already created an RSS feed using RSS.app, but several important fields were not being generated correctly:

    • Some posts were missing their publishing date.
    • Some posts had no image.
    • The description was incorrect.
    • The client wanted the first paragraph of each post to appear in the feed.
    • A “Lees meer” (Read more) link was required after the introductory text.

    The existing RSS.app feed was provided for reference, and a custom WordPress plugin was developed to generate the required RSS feed.

    Expanding the Requirement: Custom XML

    Shortly afterward, the client asked whether the service was limited to RSS feeds or whether other XML formats could also be created.

    The requirement turned out to be completely different from the original RSS project.

    The client was building a website for Boender Outdoor and wanted to display Kiyoh customer reviews on the website. Kiyoh provided review information through an XML feed, and the client wanted functionality similar to another website that was already displaying reviews using XML data.

    The goal was to make the review information available on:

    boenderoutdoor.nl/reviews

    The client subsequently provided the Kiyoh XML feed URL and confirmed that the requirement was to import the review feed and display it on the website.

    Reading the External XML Feed

    After analyzing the requirement, the technical approach was straightforward:

    1. Retrieve the XML feed from Kiyoh.
    2. Read and process the review data.
    3. Make the review information available inside WordPress.
    4. Display the reviews on the client’s website.
    5. Allow the website’s existing design to control the presentation.

    The client already had a design in mind, so the implementation focused primarily on processing the XML data rather than creating a new review interface from scratch.

    This distinction is important in XML integrations: data processing and front-end presentation are often separate layers. A reliable feed integration should first make sure that the external data can be retrieved and interpreted correctly before worrying about styling.

    A Production Issue Six Months Later

    The project returned in December 2024 when the client reported that the original XML feed on Jonglogistiek.nl had stopped working.

    The timing was critical because the client was preparing to launch an app that depended on the XML feed that same day.

    The client provided access, and the issue was fixed quickly.

    The feed URL remained:

    jonglogistiek.nl/rssfeed.xml

    After confirming that the feed was working again, the client placed an order for the fix.

    This was an example of an important characteristic of XML integrations: the feed URL itself can become part of another application’s infrastructure. Once an app, portal, or external service depends on a feed, keeping that endpoint operational becomes important.

    The PHP 8.3 Compatibility Problem

    The next major issue appeared in August 2025.

    The client upgraded the Boender Outdoor website to PHP 8.3, after which the Kiyoh review integration stopped displaying reviews correctly.

    The client explained that a custom plugin was responsible for retrieving and processing Kiyoh’s XML feed hourly. The plugin provided shortcodes for displaying review statistics and reviews throughout the website.

    Interestingly, some parts of the integration were still working.

    The client reported that the review information at the top of the page was working, while another section displayed:

    “Geen reviews gevonden”

    meaning “No reviews found.”

    The client wanted the review widget on the reviews page restored to its previous working state.

    Diagnosing a Live WordPress Website

    Because the website was live, the repair needed to be handled carefully.

    Access initially became a challenge. The supplied WordPress credentials did not work, and the client encountered login problems as well. The client eventually disabled the firewall and provided working access, allowing the troubleshooting process to continue.

    Once access was available, the focus was narrowed to the existing Kiyoh Review Verwerker plugin.

    The client specifically clarified that:

    • The existing styling was already correct.
    • The plugin was already responsible for the XML functionality.
    • The problem was that reviews were no longer being loaded on the reviews page.
    • The desired presentation should remain unchanged.

    This made the task a targeted compatibility/debugging job rather than a complete rebuild.

    Restoring the Review Display

    The existing review system was investigated and the review display issue was fixed.

    The client had also requested that the reviews remain limited to 25 reviews per page. During the fix, it was confirmed that this limit was already configured, so no additional change was necessary for that requirement.

    The client was informed that the issue had been fixed and was directed to the reviews page for verification.

    The Technical Lesson

    This project demonstrates why upgrading PHP versions on WordPress websites can expose problems in older custom integrations.

    A site can appear to be functioning normally while a particular data-processing component silently stops working. In this case, the website’s styling and surrounding review interface were still present, but the external XML review data was no longer being displayed correctly.

    Rather than rebuilding the entire system, the better approach was to:

    • Identify the failing component.
    • Preserve the existing design.
    • Preserve the existing plugin architecture where possible.
    • Check the external XML source.
    • Investigate the data-processing path.
    • Restore the review output.
    • Verify the existing pagination requirement.

    What This Project Shows

    This project involved several different types of WordPress XML work over time:

    1. Custom RSS feed development

    A standard RSS service was not producing the required post data, so a custom WordPress feed was created.

    2. Custom XML integration

    The requirement expanded into processing an external Kiyoh XML review feed.

    3. WordPress plugin development

    The XML processing was integrated into a custom WordPress plugin with shortcodes for displaying review information.

    4. External data retrieval

    The website depended on XML data supplied by an external review platform.

    5. PHP compatibility troubleshooting

    After a PHP 8.3 upgrade, the review display stopped functioning correctly and required debugging.

    6. Production maintenance

    The issue was resolved on a live website while keeping the existing styling and functionality intact.

    Conclusion

    What began as a simple RSS feed requirement eventually became a longer-term XML integration and maintenance relationship.

    The project illustrates an important principle in WordPress XML development:

    A feed is not just an XML document—it can become a critical data bridge between WordPress, external platforms, widgets, and applications.

    When that bridge stops working because of a PHP upgrade, changes in external XML data, or plugin compatibility issues, the solution requires more than simply checking whether the XML file exists. The complete flow—from external data retrieval to WordPress processing and final display—needs to be examined.

    This case is a good example of how custom XML development can evolve into ongoing integration, troubleshooting, and maintenance work.

  • Case Study 5: XML Job Feed and Predictable Vacancy URLs for RecruitNow

    Category: XML Feed Development
    Industry: Recruitment / Job Listings
    Platform: WordPress
    Integration: RecruitNow / Indeed
    Project Type: Custom XML Feed & Vacancy URL Architecture

    Project Overview

    A recruitment website needed a way to provide its job vacancies through an XML feed while also giving each vacancy a predictable URL based on a unique vacancy ID.

    The requirement was intended to support integration with RecruitNow and job boards such as Indeed, where a predictable vacancy URL could be generated automatically rather than relying on the existing job title-based URL.

    The project involved two connected requirements:

    1. Create a custom XML feed containing vacancy information and a unique vacancy ID.
    2. Create a predictable URL structure using that same ID and redirect it to the actual vacancy page.

    For example:

    https://baantjeuitzendbureau.nl/vacatures/12345

    would redirect to the actual vacancy page:

    https://baantjeuitzendbureau.nl/vacatures/orderpicker-logistiek-medewerker/

    The key idea was to use the same unique identifier in both the XML feed and the redirect URL.

    The Challenge

    The website’s existing vacancy URLs were based primarily on job titles.

    For example:

    /vacatures/orderpicker-logistiek-medewerker/

    The client explained that Indeed required a predictable URL structure containing a vacancy ID. The existing URLs did not provide that ID in a predictable position.

    This created a problem for the external feed integration.

    A job portal should be able to receive a vacancy ID from the XML feed and construct a URL without needing to know the actual title or permalink of the vacancy.

    The proposed structure was:

    /vacatures/{vacancyId}

    For example:

    /vacatures/12345

    The system would then identify the vacancy associated with 12345 and redirect the visitor to the actual vacancy page.

    The client specifically requested this type of URL-and-redirect behavior.

    The Proposed Solution

    The proposed architecture connected the XML feed and redirect system through a common vacancy ID.

    Step 1 — Identify the Vacancy ID

    Each vacancy would have a unique identifier.

    For example:

    vacancyId = 12345

    This ID would become the stable reference for the vacancy.

    Step 2 — Include the ID in the XML Feed

    The XML feed would expose the vacancy ID together with the vacancy information.

    A simplified feed item could look like:

    <vacancy>
    <vacancyId>12345</vacancyId>
    <title>Orderpicker Logistiek Medewerker</title>
    <detailUrl>
        https://baantjeuitzendbureau.nl/vacatures/orderpicker-logistiek-medewerker/
    </detailUrl>
</vacancy>

    The important part is that vacancyId remains consistent with the identifier used by the redirect URL.

    The original project discussion also specified that the same ID should be available in the XML feed so RecruitNow could construct the predictable URL.

    Step 3 — Create the Predictable Vacancy URL

    A separate URL pattern would be made available:

    https://baantjeuitzendbureau.nl/vacatures/{vacancyId}

    For example:

    https://baantjeuitzendbureau.nl/vacatures/12345

    This URL does not contain the job title.

    That makes it predictable and suitable for an external system to construct automatically.

    Step 4 — Redirect to the Actual Vacancy

    When someone visits:

    /vacatures/12345

    the WordPress implementation would:

    1. Extract 12345 from the URL.
    2. Find the corresponding vacancy.
    3. Determine its actual permalink.
    4. Redirect the visitor to that page.

    Conceptually:

    /vacatures/12345
        ↓
Find vacancy ID 12345
        ↓
Find actual vacancy URL
        ↓
/vacatures/orderpicker-logistiek-medewerker/

    This separates the stable external identifier from the changeable public vacancy URL.

    Why This Architecture Is Useful

    Job titles can change.

    For example, a vacancy might initially be published as:

    /vacatures/orderpicker/

    and later become:

    /vacatures/orderpicker-logistiek-medewerker/

    If an external platform depends directly on the title-based URL, such changes can create broken links or require the external feed configuration to be updated.

    A vacancy ID provides a more stable reference:

    /vacatures/12345

    The actual destination can change internally while the external URL remains predictable.

    This is particularly useful when a third-party recruitment platform needs to construct vacancy URLs automatically.

    XML Feed + Redirect Architecture

    The complete concept can be represented as:

                     WordPress Vacancy
                        │
                        ▼
                Unique Vacancy ID
                     12345
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
        XML Job Feed        Predictable URL
        vacancyId=12345     /vacatures/12345
             │                     │
             ▼                     ▼
        RecruitNow /          WordPress
           Indeed             Redirect
                                   │
                                   ▼
                         Actual Vacancy Page

    The XML feed and redirect mechanism therefore use the same identifier as the connection point.

    Initial Project Scope

    The original custom offer covered the setup of the XML feed and redirect URL functionality for RecruitNow. The offer included XML feed creation and redirect URL setup.

    During the discussion, the client confirmed that the XML feed needed to contain vacancy information and that the redirect should work using a unique ID.

    However, before implementation could be completed, the client explained that their original brief had been based on the wrong solution.

    The order was subsequently canceled while the client clarified the revised requirement.

    The client later returned with a more specific requirement: create an additional URL ending in the vacancy ID and redirect that URL to the actual vacancy detail page.

    Project Status

    This case study represents the technical analysis and proposed implementation approach, rather than a completed production deployment.

    The original order was canceled before the implementation was completed because the client’s requirements changed.

    That distinction is important: the case study demonstrates the technical problem, architecture, and proposed solution without claiming that the final system was successfully deployed.

    Key Takeaways

    This project demonstrates an important principle when building XML feeds for third-party job platforms:

    The feed and the destination URL should have a reliable common identifier.

    Instead of depending entirely on a changing job title or permalink, a unique vacancy ID can provide a stable reference between:

    • WordPress vacancy records
    • XML feed items
    • RecruitNow
    • Indeed
    • Predictable external URLs
    • Internal redirects

    A well-designed integration can therefore look like:

    WordPress
   ↓
Vacancy ID
   ├── XML Feed
   └── Predictable URL
          ↓
      Redirect
          ↓
Actual Vacancy Page

    For recruitment websites integrating with external job platforms, this approach can make the feed and URL architecture more predictable, maintainable, and easier for third-party systems to consume.

    Need a Custom XML Job Feed?

    If your WordPress website needs a custom XML, RSS, or job feed for a recruitment portal, job board, ATS, or third-party platform, the feed can be mapped to your existing WordPress vacancy structure and the required external format.

RSS
Follow by Email
Facebook
X (Twitter)
LinkedIn
Share
WhatsApp

Powered by
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
Powered by