A company with more than one product tends to end up with more than one blog. It feels like the tidy thing to do. Each product gets its own site, each site gets a blog section, and each blog section gets a promise that someone will keep it fed.
Then reality arrives. One product is having a busy month and its blog fills up. Another is quietly doing its job and has nothing to say, so its blog sits there with a post from March at the top. A third never got past the placeholder. Visitors notice. Search engines notice. The team notices too, and the noticing turns into a small, permanent guilt about the blogs nobody is writing.
We run a small group of products under one company, and we had exactly this problem. So we did the opposite of tidy. We collapsed everything into one blog.
One blog, one tag per product
Every post the company writes now lives in a single Lavvus blog. When a post is about a particular product, it carries that product's tag. That is the whole system. There is no second blog to keep alive, no second editor to log into, no second subscriber list to grow.
Each product website reads that one blog through the API and keeps only the posts carrying its own tag. The company's own site reads the same blog with no filter at all, so it shows everything. Same source, four front doors, and each door only lets through what belongs to it.
The part that surprised us is how much this changed the writing, not just the plumbing. When there is one blog, there is one editorial calendar. The question is no longer "has product X posted lately", it is "what does the company have to say this week, and which product is it about". Some weeks the answer is the busy product. Some weeks it is the quiet one, precisely because it has been quiet and deserves a turn. Nothing goes silent for two cycles because nothing has its own silence any more.
Why tags, and not separate blogs
A tag is a very small thing to hang a whole architecture on, so it is worth saying why it holds.
A separate blog per product duplicates everything: the subscriber list, the feed, the sitemap, the authority a domain slowly earns from being linked to. Split four ways, each piece is a quarter as useful. Backlinks land on four domains instead of one. A reader who follows one product never hears about the others. The company's writing, taken together, never adds up to a body of work anywhere.
A tag duplicates nothing. The post exists once, at one canonical URL on the company's site. The product site that displays it points its canonical link back there, so search engines see one page, not four copies of it competing with each other. The subscriber list is one list. The feed is one feed. When a product site goes through a redesign, the writing does not move, because the writing was never really there. It was always in the blog, and the site was only ever a view of it.
And tags are cheap to change. A post that started as a product announcement and turned into something broader can lose its tag and become company writing. A new product gets a new tag and a filter, and it has a fully stocked blog on day one if any of the older posts apply to it.
What a site needs
Very little. Fetch the blog's posts, keep the ones with your tag. That is it:
const res = await fetch("https://lavv.us/api/v1/public/blog/your-blog/posts?per_page=50", {
headers: { Authorization: `Bearer ${process.env.LAVVUS_API_KEY}` },
});
const { data } = await res.json();
const ours = data.posts.filter((p) => p.tags.some((t) => t.slug === "your-product"));
The site renders those posts in its own design, with its own typography and its own navigation, and nobody visiting could tell the content is shared with three other sites. On each post page the site sets a canonical link to the post's home on the company blog. When a post is published or edited, the blog calls a small webhook on each site so its cache clears and the change is visible in seconds rather than whenever the cache happens to expire.
That is the entire integration. We have it running on four sites, built by the same people who wrote the posts, and the newest one took an afternoon.
What we would tell someone starting today
Start with one blog. Even if you have one product. Especially if you think you will have two.
The temptation to give every product its own blog comes from imagining the future in which every product has a writer. That future rarely arrives. The future that does arrive is one where the company has a voice, and that voice is sometimes about one product and sometimes about another, and it wants one place to live. A tag is enough to route it. The API is enough to display it anywhere. Everything else is a website's job, and websites are good at that.
One blog, many front doors. It is less tidy on the whiteboard and a great deal tidier in practice.
A footnote, because we said we would grow in public. For a long time the RSS feed on every Lavvus blog stopped at fifteen items, no matter how many posts a blog had. Nobody had decided that; it was a default that was never revisited. The consequence only surfaced on a site that builds its sitemap from the feed: it had twenty posts published and fifteen in its sitemap, and the five oldest were quietly unreachable to search engines for months. The feed now carries twenty items, and we are looking at whether it should page rather than cap at all. The lesson is not really about RSS. A limit that nobody remembers setting is a tax on your most productive users, paid silently, and you find out about it last.
