Pluribox

I discovered a problem I had never really considered when using a domain with a previous life:

Changing the website does not necessarily change what the rest of the internet thinks the domain is.

I’m building Pluribox on pluribox.com. Today it is a completely unrelated software product, but years ago the same domain was used by a parcel-forwarding company.

The new site had been live and indexed, so I assumed the old identity would gradually disappear.

It wasn’t that simple.

When I started testing the name across search engines and AI tools, I found quite a mix of old and new information.

Google sometimes understood the current Pluribox correctly. In other searches, however, it treated “Pluribox” as an ambiguous term and surfaced unrelated products or the previous company.

Perplexity (the AI) was by far the worst. Even when I asked about pluribox.com, it did not appear to visit the current site at all and even misled me into thinking that it did - when in fact it never did by the way. It kept pulling information from third-party sources and gave me an outdated description of the old business.

Then I checked Meta’s Sharing Debugger.

It was still holding Open Graph data scraped in 2023, including:

“Pluribox - Parcel Forwarding - Shop in European Union from anywhere!”

That was a useful reminder that updating your own site is only one part of changing a domain’s identity.

So far I’ve been working through the problem by:

* making the current product definition much more explicit on the site

* adding an About page that clearly disambiguates the present platform from the former business

* adding structured data linking the website, software product and official profiles

* checking Google Search Console and Bing indexing

* allowing the relevant AI/search crawlers

* refreshing old social-preview caches

* contacting third-party databases that still associate the domain with the previous company

* making the product description consistent across the website, X and YouTube

Some of the changes are already propagating. Meta now shows the current metadata, Google increasingly understands the new product, and I’m waiting to see how long the wider cleanup takes.

The domain in question is Pluribox. I’m rebuilding it around a modular selling system for digital products that works from the website you already own.

If you’re curious, this is the current site:

https://pluribox.com/?utm_source=indiehackers&utm_medium=community&utm_campaign=prelaunch&utm_content=domain_identity_post

I’d be especially interested to hear from anyone who has reused or bought a domain with an existing history.

Did Google, AI tools or third-party databases keep confusing the old and new businesses?

And if so, what actually helped?

One thing I've learned while building Pluribox: not every seller wants the same embedded checkout experience.

Our original assumption was that sellers wanted a complete product widget.

But some sellers already have a page that does the selling. They don't need the image, description, and price again. They might just need a clean Buy button.

Others want to build trust by showing reviews wherever they make sense on their site.

So we made the embed modular.

You can now choose what actually renders on your page:

* The full product box

* Just the Buy button

* Just the reviews section

Buy Button mode keeps things clean.

Reviews can now also be embedded independently, with a friendly "No reviews yet" state so new sellers have a path to their first review - even if their sales happen elsewhere.

Existing embeds remain unchanged. Also built a test harness to verify that the new and old versions render identically.

Next up: reducing friction for free products. If a seller only wants to collect an email address, the embed will handle it directly inline on the page—no popup required.

I'm curious: if you sell digital products, would you rather have a full product widget, or have complete control to embed only the pieces you need?

Pluribox (embedded checkout for selling digital products on your own site, you stay the merchant of record) is still pre-launch, but as of this week our pricing is public: pluribox.com/pricing

A few decisions from behind the scenes:

Percentage-only, no flat fees. Free is 5% per sale, Starter is EUR 19/month at 2%, Pro is EUR 49/month at 0%. There is no per-sale flat fee on any plan. If you sell a EUR 3 product, a typical $0.50 flat fee is an extra 17% before anyone mentions percentages. Low-ticket sellers deserve better arithmetic.

We put our break-even points on the page. There is a slider on the pricing page that shows exactly what you would pay on each plan at your monthly sales level, with the crossover points marked: Starter pays for itself at about EUR 633/month of sales, Pro at EUR 1,500. Most pricing pages make you work this out yourself. I feel that showing when NOT to upgrade is what earns the upgrade later.

Compliance is never paywalled. Tax calculation, EU reverse charge, order-level audit trails: identical on the free plan and on Pro. Charging extra for the parts that keep a seller compliant never sat right.

The site itself is two hand-written static HTML pages on Cloudflare.

Waitlist is open at pluribox.com if any of this resonates. And I would honestly love this community's eyes on the pricing page: what would make you trust it more, and what would make you close the tab?

Pluribox is a checkout that lives on YOUR site so buyers never leave your page, and you stay the merchant of record through your own Stripe account. This week I extended that philosophy to the inbox.

Until now, every buyer email (purchase confirmation, download link, review request) went out looking like my platform. Functionally correct but users may want more: the sale is the seller's, so the email should be too.

What shipped:

* Sellers can customise the subject and intro of every buyer email, with a live preview rendered by the exact same code that sends the real thing. No "preview drift" possible, by construction.

* Their logo, colours and font on every email. Their name as the sender.

* Review request emails that automatically show the review reward when a product has one configured, so the email can never promise something the product page doesn't.

* Pro sellers can send from their own domain (noreply@theirbrand.com) with guided DNS verification. Every plan still gets solid deliverability from our shared domain.

Three things production testing taught me this week: email clients ignore flexbox entirely (learned it once months ago, the lesson paid rent again), Cloudflare replaces your API's 502 responses with its own HTML error page so your frontend never sees the real error, and DNS negative caching means a verification check that ran before your records existed can keep saying "not there" after they are.

[Solo founder, non-technical, building with my AI assistant.]

First post to get things rolling. Pluribox is now on Indie Hackers.

Quick version: it's embedded checkout for digital products. The whole purchase happens in an overlay on your own site, so buyers never get redirected away. One script tag, your own Stripe, you stay the merchant of record.

Pre-launch and solo. I’ll be sharing milestones, dead ends, and some things I learn along the way. Waitlist is open at pluribox.com if you'd like to follow along.