In July 2024, we worked with Kiierr to develop a custom Google Product Review Feed for its e-commerce product and review data.
The project involved transforming product review information into a structured XML feed based on Google’s Product Review Feed requirements, making the data easier to consume through Google’s product-review ecosystem.
This project is a good example of how a standard website’s product and review information can be converted into a specialized XML format for an external platform.
The Challenge
Product review data is often stored inside an e-commerce website in a format designed primarily for website visitors.
External platforms such as Google require that information to follow a specific XML structure, with appropriate elements and relationships between products, reviews, ratings, and other relevant information.
For Kiierr, the requirement was to create a dedicated feed that could present its product review information in a format aligned with Google’s Product Review Feed specification.
The key challenge was not simply generating XML. The feed needed to:
Follow the required XML structure.
Represent product and review information correctly.
Map the website’s available data to the appropriate feed fields.
Handle product identifiers and review-related information.
Produce a consistent, machine-readable feed.
Provide a dedicated feed URL that could be accessed by the external platform.
Our Solution
We developed a custom Google Product Review Feed specifically for Kiierr.
Rather than relying on a generic XML export, the feed was structured around Google’s product-review feed requirements.
The development process included:
1. Data Mapping
The available product and review information was mapped to the corresponding fields required by the Google Product Review Feed format.
This included determining which information should be used for products, reviews, ratings, and other associated data.
2. Custom XML Generation
A dedicated XML feed was created to generate the required product-review structure dynamically.
This allowed the feed to represent the website’s review data in a structured format rather than requiring manual XML updates.
3. Product and Review Relationships
Product information and associated reviews need to be represented consistently so that an external system can understand which review belongs to which product.
The feed therefore handled the relationship between product information and its corresponding review data.
4. Structured Feed Output
The final implementation provided a dedicated XML feed endpoint that could be accessed independently from the main website.
This makes it possible for an external service to retrieve the structured data without depending on the presentation layer of the website.
Why Custom Feed Development Matters
A product-review feed is different from a conventional RSS feed.
An RSS feed primarily communicates content updates such as articles, posts, or other published items. A product-review feed has a much more specific data model and must represent information such as:
Products
Product identifiers
Reviews
Review authors
Ratings
Review content
Review dates
Product/review relationships
For this reason, simply exporting website content as XML is not enough.
The important part of this type of project is understanding the target platform’s specification and building the feed around that specification.
Project Outcome
The Kiierr project resulted in a dedicated Google Product Review Feed developed in July 2024.
The project demonstrated our ability to work with specialized XML specifications, map e-commerce data into structured formats, and develop custom feeds for third-party platforms.
It also forms part of our broader experience developing XML, RSS, product, real-estate, job, API, and other custom data feeds.
Our Experience With Custom XML Feeds
Over the years, we have worked on a wide range of feed-related projects, including:
Google product and review feeds
RSS feeds
Real-estate XML feeds
Job-board XML feeds
API-to-XML integrations
XML-to-CSV conversions
XML-to-XML transformations
Custom PHP feed generators
Product data feeds
Marketplace and portal feeds
Each project requires a slightly different approach because the destination platform often has its own XML structure, required fields, validation rules, and data-mapping requirements.
Need a Custom Product or XML Feed?
If your website already contains product, review, property, job, or other structured data but you need it exported into a specific XML format, we can develop a custom feed around your requirements.
We can help with:
Custom XML Feeds • Google Feeds • RSS Feeds • Product Feeds • API-to-XML • XML-to-XML • XML Troubleshooting
Have an existing feed that is no longer working correctly? We can also investigate and fix XML structure, data mapping, validation, and feed-generation issues.
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.
From a Simple “Add Brand” Request to Reliable Marketplace Feed Integration
Project Overview
A Danish boat-sales business was migrating from its old domain, dansksejlogmotor.dk, to a new branded domain, ditbaadsalg.dk.
The domain migration itself was straightforward, but it created an important technical problem: the business relied on XML feeds to distribute its boat listings to external marketplaces, including DBA.dk and ScanBoat.
After the migration, the feeds were still referencing the old domain and several pieces of structured listing data were not being transferred or displayed correctly.
What initially started as a small request to add a brand field eventually became a broader XML feed debugging and optimization project involving:
Domain migration
XML field mapping
Product/boat specifications
Category mapping
Description formatting
Image ordering
Sold/out-of-stock filtering
Price synchronization
Scheduled feed updates
DBA validation
ScanBoat validation
Comparison with the previously working feed
The project demonstrates an important principle in XML feed development: generating valid XML is only one part of the job. The receiving marketplace must also interpret every field correctly.
1. The Initial Problem
The business had migrated from:
dansksejlogmotor.dk
to:
ditbaadsalg.dk
The existing DBA and ScanBoat feeds were still containing URLs from the old domain.
The first request was therefore to update the feeds so they would work with the new domain.
Shortly afterward, the client identified another requirement:
The DBA feed also needed to include the boat’s brand value.
The client explained that the brand was already entered on the website, but the value was not being included in the XML output.
At this stage, the task appeared to be a relatively small XML modification.
2. Adding the Brand Field Exposed Other Feed Problems
After the brand field was added, the client noticed that some boat descriptions were no longer appearing correctly in the feed.
For example, the description for a boat such as Saga 26 HT appeared correctly on the website but was being displayed incorrectly in the feed.
Investigation showed that the existing function responsible for cleaning descriptions for XML output was not working correctly.
A new description-cleaning approach was therefore required.
At the same time, another issue appeared: images were being selected in the wrong order.
Instead of:
Main image
Second image
Third image
etc.
the feed could contain images in an unexpected order.
The client specifically requested that the primary product image should always be the first image.
3. Fixing Image Ordering
The image logic was updated so that the featured image was placed first in the XML media output.
The change was subsequently applied to both the DBA and ScanBoat feeds.
This was important because marketplace feeds are not simply data exports. The order and structure of repeated elements can affect how the receiving platform displays a listing.
The client later confirmed that the image issue had been resolved.
4. Sold Listings Were Still Appearing
Another issue then surfaced.
The client found several boats that had already been sold—or were hidden drafts—still appearing in the feed.
The affected listings included:
Awi 23
Svensk træbåd
Princess 415
Monterey 254
Coaster 600 DC
Cranchi Smeraldo
The website already had a condition intended to exclude products where _stock_status was outofstock.
This required checking the relationship between the WordPress/WooCommerce product status and the actual feed-generation logic.
This illustrates another common XML-feed problem: the website can display a listing correctly while the feed-generation rules use different conditions.
5. Marketplace-Specific Field Mapping
Once the basic feed issues were addressed, DBA began reporting problems with structured fields.
Some important information was appearing as:
Length: Not specified
Engine type: Not specified
Seats: Not specified
Type: Other
The client requested that the feed correctly map the boat information to DBA’s expected fields.
The investigation then moved beyond simply producing XML.
The receiving platform’s expected field names, formats and category structure became part of the debugging process.
The client also supplied the old feed as a reference because it had previously worked correctly.
This provided a valuable baseline:
Old working feed → New feed → Side-by-side comparison
6. Reproducing the Old Working Feed
A particularly important requirement emerged during the project.
The client wanted the new feed to be as close as possible to the previously working feed from the old domain, while adding the new brand field.
The requested approach was essentially:
Make the new feed identical to the old feed, change the sender/domain, add the required fields, and preserve the existing formats.
The requested structured fields included:
category_id
engine_included
engine_type
engine_brand
engine_power_hp
fuel_type
length_feet
along with the previously added brand field.
The updated feed was then regenerated with these additional fields.
7. Category Mapping Became a Critical Issue
One of the more interesting problems was the DBA category.
At one point, the client discovered that a value such as:
<category>37000</category>
was appearing in the feed and suspected that this was responsible for the incorrect marketplace display.
The discussion then moved toward whether DBA expected a category value or a category_id value.
A change to category_id was tested, but DBA subsequently indicated that the system was undergoing a migration to its new Dealer Hub system. The category mapping therefore could not be treated as an isolated XML problem—the receiving platform’s import system was also changing.
The category change was eventually reverted as requested.
Lesson
When troubleshooting marketplace feeds, it is important to distinguish between:
Feed-side problems
and
Marketplace-side import problems.
A perfectly generated XML feed can still display incorrectly if the marketplace has not reprocessed it, is changing its import system, or is interpreting a field differently.
8. Feed Updates Were Not Happening Quickly Enough
Later in the project, the client noticed that:
A boat with a new price was still showing its old price in the marketplace.
A sold boat was still appearing in the marketplace.
The client suspected that the feeds were not updating.
The feed itself needed a more reliable update mechanism.
A cron job was added so the feed would be refreshed every five minutes.
This was an important improvement because there are actually two separate stages:
WordPress data → XML feed → Marketplace import
Updating the XML feed does not necessarily mean the marketplace has immediately imported the new data.
That distinction became particularly important during DBA testing.
9. DBA and ScanBoat Required Different Validation
The project involved two external platforms:
DBA
ScanBoat
Even though both consumed XML feeds, their expectations and processing behavior were not necessarily identical.
The client reported that ScanBoat was receiving correct information from the old feed but not from the new feed.
The requirement was to make the new ScanBoat feed reproduce the same data and formatting as the old feed, including decimal formatting.
The ScanBoat feed therefore required its own validation rather than assuming that fixing the DBA feed would automatically solve the ScanBoat integration.
10. Description Formatting
After the marketplace began receiving the updated data, another presentation issue became visible.
The boat description and technical specifications were appearing as one continuous block of text.
The client wanted the content separated into readable sections such as:
Description
The boat’s main description.
Dimensions
Feet
Length
Width
Draft
Displacement
Hull type
Berths
Mechanical
Engine
Batteries
Shore power
Equipment
Cockpit equipment
Cabin equipment
Refrigerator
Toilet
Other accessories
The feed output was adjusted so the information would appear with improved separation and readability.
The client subsequently confirmed that the text had been separated in both feeds.
11. Testing the Feed Against Real Listings
Rather than relying only on XML inspection, the project involved checking actual listings across the website and the marketplace.
For example, a specific boat was compared between:
Website listing → XML feed → DBA listing
The client supplied actual listing URLs when an inconsistency appeared, allowing the feed data to be compared with what DBA was displaying.
This approach is especially important for marketplace integrations.
A feed can be:
syntactically valid,
accessible,
correctly formatted,
and still produce an incorrect listing because the receiving platform interprets a field differently.
12. The Final Testing Stage
Toward the end of the project, the client reported that ScanBoat was working correctly.
DBA was also displaying the listings more accurately, although additional marketplace-side processing and testing remained necessary.
The final testing included new boat listings as well as existing/used boats.
The project also involved checking whether length in feet was being transmitted correctly. The feed contained the length_feet field, while the client continued checking the behavior on DBA’s side.
The client eventually confirmed on December 2, 2025:
“Job is done :-)”
Technical Challenges Solved
The project ultimately addressed a much broader set of requirements than the original brand request.
Area
Issue
Solution / Approach
Domain migration
Old domain URLs remained in feeds
Updated feed output for the new domain
Brand
Brand existed in WordPress but was missing from XML
Added brand mapping
Description
Text was incorrectly formatted
Updated XML-safe description processing
Images
Primary image was not consistently first
Featured image moved to first position
Sold listings
Out-of-stock items appeared in feeds
Checked feed filtering conditions
Category
Marketplace category was interpreted incorrectly
Compared category/category ID requirements
Boat specifications
Length, engine and other fields missing
Added and mapped structured fields
Price
Updated prices were not immediately visible
Verified feed output and marketplace reprocessing
Feed freshness
Changes were not reflected quickly
Added a five-minute cron refresh
ScanBoat
New feed differed from old working feed
Compared and adjusted output
Formatting
Description/specifications appeared as one block
Improved output separation
Validation
Feed output and marketplace display differed
Tested actual listings end-to-end
The Most Important Lesson
This project demonstrates why XML feed development is more than generating XML syntax.
A successful marketplace feed has at least four layers:
1. Source data
WordPress custom fields, product data, images, prices and status.
↓
2. Feed mapping
Correct XML tags, values, data types, formatting and filtering.
↓
3. Feed delivery
A stable, accessible and regularly updated XML endpoint.
↓
4. Marketplace interpretation
DBA, ScanBoat or another portal imports and maps the feed according to its own specifications.
A problem can occur at any of these layers.
That is why simply opening an XML URL in a browser is not always enough to determine whether a feed integration is working correctly.
Result
The project evolved from a small feed customization into a complete troubleshooting and synchronization exercise.
The final work addressed:
New-domain feed output
Additional structured fields
Brand mapping
Boat specifications
Image ordering
Description cleaning
Description formatting
Listing filtering
Category handling
Feed refresh scheduling
DBA testing
ScanBoat testing
Comparison with the previous working feed
Most importantly, the project ended with the client confirming that the job was complete and expressing interest in working together again.
What This Case Study Shows
For businesses moving websites, changing domains, adding marketplace integrations, or replacing an existing XML feed, the safest approach is not to build the new feed from scratch without reference.
Instead:
Preserve the existing working feed structure where possible.
Compare old and new feeds item by item.
Map every important custom field explicitly.
Treat images as structured data, not just URLs.
Filter sold, hidden and unavailable listings correctly.
Validate marketplace-specific categories and field formats.
Understand the difference between feed generation and marketplace import.
Allow for marketplace caching and scheduled imports.
Test real listings from the website through the feed to the marketplace.
This methodology can significantly reduce the risk of losing or incorrectly displaying listings after a website migration.
Need a Custom XML Feed?
If your WordPress website needs a custom XML, RSS or JSON feed for a real estate portal, marketplace, directory, advertising platform or another external system, the important question is not simply:
“Can you generate XML?”
The real question is:
“Can the receiving platform correctly understand and use the data?”
That is where careful field mapping, feed validation and real-world testing make the difference.