WP to XML

Tag: WordPress Feed

  • 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 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.

Powered by