What should a car dealership website include?

Start with the buyer’s decision

A dealership visitor needs more than a set of photos. They need a quick answer about a suitable vehicle: make, model, year, price, mileage, condition, and a clear way to ask a question or request a visit. The website therefore connects the inventory display with the team workflow that keeps it current and handles inquiries.

Treat the website as the showroom front and a first layer for qualifying a question. Every visible field should have a source, an owner, and a known review point. Fields or automation that have not been agreed are proposed requirements that belong in the project scope.

• Comparable vehicle data instead of repeated ad copy.
• Search and filters that narrow the visitor to a manageable set.
• An inquiry that keeps its context: vehicle, question, and preferred contact method.

The vehicle record structure

Create a consistent template for every vehicle before designing cards. A useful minimum may include branch or location, make, model and trim, model year, transmission, fuel, mileage, price, and stock number. Add fields your team actually needs, such as inspection status or expected availability, after agreeing what each field means and how it is updated.

Standardise units, currencies, and missing values. Do not show “not available” as zero, and do not leave price or status to visitor guesswork. When information changes, the team should know whether to edit the record or create a new one, and who reviews it before publication.

Filters that support a choice

Start with filters that change the buying decision: make or model, price, year, body type, transmission, fuel, and mileage. Do not add a long list simply because it is possible; a good filter reduces results and remains understandable on a phone.

Show active filters and make them easy to remove, with a clear empty-results state. Results should remain understandable after combining conditions, and the team should agree whether reserved or sold vehicles are included in search.

• A clear default sort, such as newest or lowest price.
• A count or message that describes results without promising availability at contact time.
• A way to clear filters and return to all available vehicles.

Specifications and photos that build trust

Place specifications in a consistent location so visitors can compare cards and detail pages. Keep photos tied to the same vehicle, and give them accurate text descriptions. A set may include exterior and interior views, a dashboard photo, or a damage photo where that suits the dealership policy; do not hide a material omission behind generic images.

The image, title, and price should point to the same record. If photos are temporary or unreviewed, include that in the editorial process before publication. Presentation quality does not prove a vehicle’s condition or history; the dealership team should explain those matters from its documented information.

Availability and stale inventory

A sold or reserved vehicle should not remain apparently available without explanation. Define clear states such as available, reserved, sold, or awaiting verification, and define the action for each state. A sold vehicle may remain on a separate page if useful, but it should not appear in available results or new suggestions.

Use a last-reviewed date or an age rule to prompt review of older listings. This is a proposed operating policy, not a confirmed function in the demonstration. If there is no automated review, create a daily or weekly list with a named owner and record what was updated.

• An empty status must not mean “available.”
• An inquiry about a sold vehicle needs a useful alternative or a clear explanation.
• Test changed prices and missing photos before launch.

An inquiry that keeps its context

An “Ask about this vehicle” action should carry the stock number or vehicle URL and visible title to the team. Ask for only what is needed: name, contact method, and message or preferred time. Visitors can choose a call, form, or WhatsApp according to what the team can actually monitor.

WhatsApp is an inquiry handoff channel, not a guarantee of a reply or a sale. Shape the initial message to mention the vehicle and any related filter or request, then agree who replies, when status changes, and how the outcome is recorded. Any additional integration or automated alert is a requirement to confirm in scope.

Reading the Mawaqe3 demonstration

The cars section on the homepage is an illustrative system preview, not a customer page or live inventory. It shows a hero image of a luxury SUV with “2023 · 48,500 JOD”, a search area labelled “Find your next car”, and two side cards for a compact SUV priced at 25,900 JOD and an executive sedan priced at 35,750 JOD. The images and names are example content for the preview, not confirmed vehicle records.

This scene demonstrates the desktop arrangement of a hero image, search area, and cards. It does not prove a data source, working filters, sold-status management, or a WhatsApp link. Those are requirements to discuss and define in a project. No separate public showroom demo is linked from this preview.

Worksheet before requesting the build

Complete this with the inventory owner and the person who follows inquiries. Unresolved answers become scope questions, not design assumptions.

• Which fields are required for every vehicle, and who owns each update?
• Which states are allowed: available, reserved, sold, or awaiting verification?
• Which filters do visitors actually use, and what is the default result order?
• How many photos are required, and who checks their vehicle match and alt text?
• When does a record become stale, and what happens when it is not reviewed?
• Which data must arrive with an inquiry on the phone or WhatsApp?
• Who reviews sold status, price, and photos before and after publication?
• How will the team accept the first release, and who owns changes afterward?

The phone is the first test point

Test the vehicle list on a small screen: check the title, price, image, and key specifications before scrolling. Filters must remain usable, actions must be clear, and a WhatsApp or call link should open without making the visitor copy a number or lose the vehicle they were viewing.

Test real cases: one result, many results, no results, a sold record, a slow image, and a long inquiry message. Review Arabic and English, text direction, and whether a table or specification card creates horizontal overflow. These are proposed acceptance tests to execute within the project scope.

Frequently asked questions

Are photos and prices enough? They can be a starting point for a small inventory, but they do not answer filtering, status, or inquiry context. The decision depends on how the dealership works, record volume, and update frequency.

Should sold vehicles be deleted? Not always. They can remain in an archive or be hidden, but the rule must be clear and they must not mix with available vehicles or imply that they can be requested.

Is WhatsApp part of the confirmed demonstration? No. The current scene shows an image, search area, and cards; WhatsApp handoff and inquiry follow-up are requirements to define in the project.

How can Mawaqe3 help? Mawaqe3 can discuss your inventory structure, test filters and inquiry context, then define a digital showroom scope that fits how your dealership operates.