Overview
In Bagisto, Per-Channel Sitemaps answer the same question for every storefront: which pages belong to this host, and this host alone?
A channel is a storefront with its own hostname, currency and category tree. Our multi-vendor marketplace runs several of them from one admin.
So the queued job processes each storefront on its own — separate files, separate links, never mixed.
One global sitemap cannot serve many storefronts
First, a sitemap serves one host. It can only list the URLs of the domain that serves it.
Generate every link with url(), and the whole file inherits one hostname — usually the admin’s own.
Instead, the easy fix flattens every storefront into one file:
|
1 2 3 4 |
// One file lists every storefront's pages under a single hostname. $urls = Product::all()->map(fn ($p) => Url::create(url('/p/'.$p->slug))); Sitemap::create()->add($urls)->writeToFile('public'); |
That file, however, mixes the US store, the UK store and a third host under one domain.
Google ignores any URL that does not belong to the host serving the sitemap; consequently, the extra storefronts quietly starve.
For example, Google’s sitemap rules make this host rule explicit: a file may only list URLs from its own host.
Generate Per-Channel Sitemaps with a pivot and a loop
The fix starts in the data model; equally, a pivot table ties each sitemap record to the storefronts it must cover.
|
1 2 |
// A pivot row links the sitemap to the channels it covers. $sitemap->channels()->sync($request->get('channels')); |
Next, the queued job loops those channels and processes each storefront in isolation, each on its own hostname.
To make every link carry the right domain, we pin the URL generator to that hostname.
|
1 2 3 4 |
// Per-Channel Sitemaps force the hostname, then scope every query. URL::forceRootUrl($channel->hostname); Product::whereHas('channels', fn ($q) => $q->where('channel_id', $channel->id)); |
Likewise, queries scope products and pages by channel, so a US item never leaks into the UK file.
Meanwhile, categories come from the nested set: the branches between the channel’s root category boundaries.
|
1 2 |
// Only the branches under this storefront's root category. Category::whereBetween('_lft', [$root->_lft + 1, $root->_rgt - 1]); |
As a result, the job writes every file under the channel’s own folder, so the disk mirrors the storefronts.
|
1 2 |
// Every file lands in the channel's own folder. 'sitemaps/'.$channel->code.'/'.$sitemap->file_name; |
Overall, Per-Channel Sitemaps hand Google exactly what it expects — one hostname, one sitemaps/{channel_code}/ folder, one file set.
Keeping Per-Channel Sitemaps honest
A channel with no hostname, for instance, falls back to the app root URL, so a blank field never breaks the job.
The job also deletes old files before writing new ones, so a retired storefront leaves no stale index.
Finally, the loop restores the root URL at the end, so sibling jobs still generate links for the admin’s own domain.
Moreover, each channel reports its hostname and files into the sitemap record, so the admin listing stays a single source of truth.
The record, notably, resolves through a proxy, exactly as in our note on swapping Eloquent models.
Final Thought
In short, Per-Channel Sitemaps are a mapping problem, not a generation problem. The URL maths was never hard.
So tie a sitemap to its storefronts, scope each query to the channel, write into its own folder. Google gets what it can use.
Be the first to comment.