The auction website pages every online and hybrid sale actually needs

A working auction website needs a specific set of pages, from the catalog to settlement. Here is what each one has to do and why.

A working auction website needs six pages at minimum: a home page listing current and upcoming sales, a catalog page with real filters, individual lot pages, a bidder or paddle registration page, a terms of sale page, and a settlement or results page once a sale closes. Everything else on the site, a consignment form, a results archive, a page for each sale category, extends that base rather than replacing it.

That sounds obvious written out. In practice, a lot of auction sites skip straight from a home page to a single flat list of items with no filters, no clear registration flow, and no page at all for what happens after a lot sells. The result is a site that looks fine in a screenshot and falls apart the moment a real sale runs through it: bidders emailing to ask when a lot closes, a registration PDF nobody can finish on a phone, and a settlement process that lives entirely in someone’s inbox.

This article walks through what each of those pages needs to do, in the order a bidder actually moves through them, from the first visit to the site through to picking up a lot after the sale.

What an auction website actually needs to do

An auction website has one job that a normal business website does not: it has to represent something that changes state over time. A lot is open, then closing soon, then closed, then settled, then archived. A restaurant’s menu page does not need to update every few minutes during dinner service. An auction catalog page does, at least in how it presents status, even if the underlying bid data comes from a separate bidding platform.

That distinction matters because it changes what “good design” means for this kind of site. A beautiful catalog page that shows stale status information is worse than a plain one that is accurate, because the entire point of the page is to tell a bidder something true about a fast-moving situation. Every page structure decision below follows from that priority: accuracy and clarity first, visual polish built on top of it rather than instead of it.

The home page: showing what is running right now

The home page’s first job is answering one question: what sales are happening, and when. A visitor who lands on an auction house’s home page is almost always there because they heard about a specific sale or are checking whether anything new has been listed. If that information is not immediately visible, the visit is wasted.

For an operation running more than one sale at a time, whether across categories or across physical locations, the home page needs to list each active and upcoming sale distinctly, with its own closing window and a link into its own catalog. A single sale operation can simplify this to one prominent block, but the principle holds either way: the most time-sensitive information goes first, above anything about the company’s history or general services.

The catalog page: where bidders spend the most time

The catalog page is the workhorse of an auction website. It is also the page most likely to be under-built, because it is easy to treat as a simple list when it actually needs to function more like a filtered search interface.

Bidders do not browse a catalog the way they browse a blog archive. They think in categories (“show me the tools”), in status (“what is still open”), and in time (“what closes soonest”). A catalog page needs filters for each of those, because without them, a sale of any real size becomes an unmanageable scroll. This is true whether the sale runs to twenty lots or two thousand: the filter structure is what keeps the page usable, not the raw lot count.

What a lot card should show without a click

Each entry in the catalog, before a bidder ever opens the full lot page, should show a photo, a title, the current status, and the closing time. That is enough for someone to decide whether a lot is worth a closer look. Cards that show only a thumbnail and a lot number push all of that decision-making onto the full lot page, which slows browsing down for no real benefit.

The lot page: enough detail to bid with confidence

Once a bidder opens an individual lot, the page needs to answer whatever question is standard for that category. A piece of equipment needs hours, model year and attachments. A piece of fine art needs provenance and condition notes. An estate sale item needs clear photos and an honest condition description. None of that is optional detail; it is the information a bidder is actually using to decide how much to bid.

Category-specific detail, one consistent template

The mistake to avoid here is building a completely separate lot page design for every category. That creates a maintenance problem and a jarring experience for anyone browsing across categories. The better structure is one lot page template with a flexible detail section: the surrounding layout, navigation and photo gallery stay consistent, while the specific fields shown, hours and attachments versus provenance and dimensions, change based on the category.

Registration: turning a visitor into a paddle number

Registration is the step where a lot of otherwise well-built auction sites lose people. A downloadable PDF that has to be printed, filled in by hand and emailed back is a real barrier, especially for a first-time bidder trying to register from a phone five minutes before a sale opens.

Building registration as a real page on the site, with the same design language as the rest of the catalog, removes that friction. The page should collect exactly what the sale needs, no more, and confirm the outcome clearly, whether that is an immediate paddle number or a message that registration is pending review. For sales that require payment authorization before bidding, the registration page hands off to whatever payment or bidding platform actually processes that step, rather than trying to replace it.

Live status: keeping the countdown honest

A countdown timer is a small detail with an outsized effect on trust. If a lot page says a lot closes at a certain time and that time passes with no change, bidders stop trusting the page, and rightly so. The status shown on the site needs to reflect what the bidding platform actually reports, including when a sale extends a closing time because a bid landed in the final moments.

Stating a time zone explicitly next to every closing time removes another common source of confusion, particularly for a sale drawing remote bidders from outside the auction house’s own region. It is a small addition, and it eliminates an entire category of “when does this actually close” messages to your team.

Timed sales and hybrid live sales need different status displays

Not every sale format closes the same way, and the website needs to reflect that difference rather than forcing every sale through one generic status display. A timed online sale typically closes lots on a staggered schedule, a few minutes apart, sometimes with an extended-bidding rule that pushes a closing time back if a bid lands in the final moments. A hybrid sale, where a live floor auction runs alongside remote bidding, closes each lot in real time as the auctioneer works through the room.

For a timed sale, the catalog page needs to show a running sequence: which lots are closed, which is closing next, and how much time remains on each of the next several. Because closings happen apart from one another rather than all at once, the settlement process usually needs to start on the earliest-closed lots while later lots are still open, which is why a settlement page built to update per lot, rather than assuming a whole sale settles in one batch, matters more here than it would for a single-event sale.

For a hybrid sale, the priority shifts toward keeping remote bidders synchronized with what is happening on the floor. That usually means a more prominent live status indicator, sometimes paired with a video or audio stream, and lot information that updates the moment the floor moves to the next item rather than on a fixed schedule. Building both of these into one flexible catalog template, rather than a single fixed layout, is what lets one auction operation run both formats without needing two separate websites.

Consignment pages: the page that brings in the next sale

Everything covered so far serves the bidder’s side of a sale. A consignment or “sell with us” page serves the other side: the person deciding whether to bring an item, an estate, a piece of equipment, or a business’s assets to your next sale rather than someone else’s.

A consignment page earns its place by answering the questions a prospective seller actually has before they ever pick up the phone: what categories you accept, roughly how the process works from initial contact to the sale itself, what a buyer premium or seller commission structure looks like in general terms, and how to get in touch to start a conversation. It does not need to quote a specific commission rate publicly, since that is often negotiated per consignment, but it should make the shape of the process clear enough that a seller is not starting from zero.

For an auction house running a public results archive, the consignment page and the archive work together: a prospective seller can look at what similar lots have brought in past sales, then reach out through the consignment page with a much clearer sense of what to expect. That link between “here is our track record” and “here is how to work with us” is one of the more overlooked pieces of an auction website’s structure, and it is a natural extension of the same page templates already described above rather than a separate project.

Settlement and results: what happens after the hammer falls

A settlement page is one of the most commonly missing pieces on an auction website, and it is one of the highest-value additions. Once a lot closes, the winning bidder needs to know, without digging through email, what they owe, including any buyer premium, how to pay, and when and how to pick up or receive the item.

Laying that out as a page rather than a one-off email reduces the number of “what do I owe and when can I pick it up” messages your team fields after every sale. A results or archive page, listing closed sales and their outcomes, serves a second purpose beyond settlement: it gives prospective sellers a reference point for what similar items have brought, and it gives search engines a growing, indexable history of your sale activity.

Site speed: why the last five minutes matter most

Traffic to an auction site is rarely evenly distributed. It spikes hard in the minutes before a popular lot or an entire sale closes, exactly the moment a slow page costs a bidder their last chance to act. Google’s own guidance on page experience treats loading speed and stability as real signals in how content is surfaced, and the broader industry data compiled in projects like the HTTP Archive’s Web Almanac consistently shows how much page weight and script bloat can drag load times down on exactly the kind of image-heavy catalog page an auction site depends on.

Practically, that means keeping JavaScript to what a page genuinely needs, serving images efficiently, and hosting on infrastructure built to absorb a traffic spike rather than buckle under one. web.dev’s ongoing work on Core Web Vitals is a reasonable frame of reference for what “fast enough” looks like on the pages that carry the most weight, the catalog and lot pages.

SEO structure for a sale calendar

Search visibility for an auction house comes from the same structural discipline as everything above: a distinct, well-built page for each sale type and each area served, rather than one general page trying to rank for all of it. Google’s structured data guidelines are explicit that schema markup should describe what is actually on the page, which is exactly why FAQ schema, service schema and breadcrumb structure only belong on a page when the visible content backs them up word for word.

That structure compounds over time. A dedicated page for farm equipment sales, one for estate sales, and a running archive of past results give search engines a growing, specific picture of what an auction house actually does, which a single flat “auctions” page never can.

Accessibility is part of the structure, not an afterthought

An auction site serves a genuinely wide range of visitors, including bidders using a keyboard, a screen reader, or a smaller phone screen under time pressure. The W3C’s WCAG guidelines lay out the baseline most public-facing sites are held to, and the practical version of that for an auction site is straightforward: forms that work with a keyboard, status information that is not conveyed by colour alone, and page structure that a screen reader can navigate in a sensible order. None of that is a separate project from the page structure described above; it is a property of building that structure correctly the first time.

What this looks like on a managed BidWebStudio build

Every page described in this article, catalog, lot pages, registration, live status, settlement and results, is included as standard structure on every plan we build, detailed in full on our features page and priced out on the pricing page. The specific fields and terminology differ by sale type: an estate sale auctioneer needs different lot detail than a farm and equipment auction, which is why the lot page template flexes by category rather than forcing every sale into one shape.

None of this replaces the bidding, payment or auction management platform you already run sales through. We build and manage the website around it: the pages a bidder actually sees, from the first visit to the catalog through to the settlement page after a lot sells. If you want to see what that looks like for your specific sale type, book a demo and we will walk through a build for your kind of sale directly.

Sources

  1. Google Search Central: Structured data general guidelines
  2. web.dev: Core Web Vitals
  3. Google Search Central: Understanding page experience
  4. HTTP Archive: The Web Almanac
  5. W3C Web Accessibility Initiative: WCAG overview

Frequently asked questions

What pages does a minimum viable auction website need?

A home page listing current and upcoming sales, a catalog page with filters, individual lot pages, a bidder or paddle registration page, a terms of sale page, and a settlement or results page. Everything else, such as a consignment page or a results archive, builds on that base.

Does the website need to run the actual bidding?

No. A managed auction website presents the sale clearly and links or embeds the bidding, auction management or payment platform you already use. The site is not a substitute for that platform, and we are not a bidding platform, an auctioneer or an escrow provider.

How many lots can a catalog page realistically handle?

With category, status and closing-time filters built into the template, a catalog page can stay usable from a handful of lots up to several hundred. The limiting factor is usually the filter structure, not the raw number of lots.

Should every sale category have its own lot page layout?

The catalog view should stay consistent across categories, but the lot page itself benefits from category-specific fields, such as equipment hours for machinery or provenance for antiques, built on one shared template rather than one-off pages.

Does a settlement page replace an invoice from our accounting system?

No. The settlement page presents what a winning bidder owes and the pickup or shipping terms in plain language on the site. Your accounting or payment system still generates the actual invoice and processes payment.

How long does it take to launch a site with this structure?

On a managed plan, a site with this full page structure typically launches in 7 to 15 days depending on the tier, with the clock starting at the onboarding call rather than at purchase.

Want a site like the one described here? Book a demo with BidWebStudio.