NewBase
Get in touch

Webflow to Astro for Marketplaces

A marketplace's Webflow site is almost always the discovery layer around a product that lives somewhere else. Moving it means preserving a lot of URLs, rebuilding the inventory as a content model, and testing the handoffs.

Get in touch

The migration stops at the transaction.

Acquisition, the handoff, and the transaction

Astro

Acquisition

  • City, category and seller pages
  • Editorial and resources
  • Curated directory content
  • URLs and the landing pages behind campaigns

The handoff

Both sides meet here

  • Signup, both sides
  • Listing search
  • Into checkout
  • Attribution

The marketplace

Transactions

  • Live listings and availability
  • Cart and checkout
  • Accounts, on both sides
  • Payouts, tax and orders
The discovery layer moves. The marketplace itself does not. The handoff between them is the part worth designing rather than inheriting, and the part a rebuild has to test on both sides.

The inventory moves as data, not as pages.

Listings rarely stand alone. They belong to categories, locations, providers and services, and those references are the part of a CMS migration worth checking item by item: a category that failed to resolve is a page that still renders and says nothing.

Listing One record, many views

Categories

Locations

Sellers and providers

Services and attributes

Categories
How inventory is grouped and browsed, in the words people use.
Locations
Where supply actually exists, which is what gets searched first.
Sellers and providers
Who owns or fulfills the listing, and a profile worth indexing.
Services and attributes
What makes one listing different from the one beside it.

Two sides, one component system.

Buyers and sellers arrive with different jobs. Shared inventory, taxonomy and components connect the two journeys without becoming two websites, and a rebuild is where that sharing gets made explicit instead of living in duplicated Designer classes.

Your marketplace

One component system

  • Landing pages
  • Proof
  • FAQs
  • Onboarding
  • Campaigns

Sellers and providers

  • Create and manage inventory
  • Receive demand
  • Maintain availability
  • Manage their own presence

Buyers

  • Find inventory
  • Filter and compare
  • Evaluate trust
  • Convert or enquire

The stack matters as much as the pages.

Astro The marketing site

What gets decided before a marketplace migration.

  1. 01

    Which URLs are load bearing

    City and category pages are usually the largest set of indexed URLs the company owns. Inventorying them and deciding what is preserved, redirected and deliberately retired is the first piece of work, not the last.

  2. 02

    What is content and what is inventory

    The test is whether the thing changes slower than you publish: a city, a category or a vendor profile is content, and live availability is not. What is not content stays in the product and is read at request time or not at all.

  3. 03

    Who owns the taxonomy

    Categories, locations and filters need one owner, because once URLs and search depend on them they are infrastructure rather than copy. A migration is the moment to find out whether anyone currently owns them.

  4. 04

    Who owns the search

    Filtering a collection is a page feature; relevance ranking over live inventory is a product feature with a backend. The size of the catalog decides which one is being rebuilt, and they cost very different amounts.

Moving the discovery layer does not move the marketplace. Live availability, checkout, accounts and payouts stay in the system running them. A migration that tried to absorb those would be rebuilding an application inside a website, which is the same mistake in a new place.

Questions about Marketplaces.

We have thousands of city and category URLs. Do they survive?

That is the main question, and it is answered by inventory rather than by assurance. Every URL currently indexed gets listed, and each one is preserved, redirected to the page that replaced it, or deliberately retired with that decision written down. Matching the address is usually possible; what nobody can promise is what search engines do afterward, because that depends on how much else changed at the same time.

What happens to our filtering and search?

It gets rebuilt to suit the catalog rather than ported. A few hundred entries can filter and sort in the page. Relevance ranking over live or user-generated inventory needs a search service behind it, with the site rendering what comes out, and if that is what the current site does then the migration keeps that arrangement rather than replacing it.

Can sellers still manage their own listings?

Wherever they do it today, they keep doing it. If that is a product feature behind a login, the migration does not touch it. If listings live in the CMS, they move to whichever content system is chosen and the editing setup is part of that decision. Authentication and the source of truth for inventory get settled before the rebuild, because both decide how much of the workflow the site can hold at all.

Can the new site still talk to our marketplace backend?

Where it exposes the data or an API, yes, and that connection is rebuilt against the new site. The signup handoff gets the most care because it is the one on the marketing side where a failure costs a real person something, and it is tested at the record that arrives rather than at the confirmation screen.

Building something else?

Reach out and see if we are a good fit.

Get in touch

Currently booking two to four weeks out.