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
brandvalue.
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 specifiedEngine type: Not specifiedSeats: Not specifiedType: 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_idengine_includedengine_typeengine_brandengine_power_hpfuel_typelength_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.