The yacht page, the fleet search, and the pages Google sees

I joined an existing Next.js site as one of the frontend developers. The site was live and selling. That shapes everything below: nothing here is a rewrite, and every change had to land on a page that was already taking enquiries.

The yacht page

The yacht page is where the decision happens. Someone has already picked a country and a week. They are on one yacht now, and they are deciding whether to send the enquiry.

It was not set up to carry that. There was no gallery, so an eighteen-guest gulet was represented by one photograph. There was no itinerary, so nobody could see where the week actually went. There was no clear place to enquire. And the page moved under you while it loaded.

I added the three things the decision needs, in the order it needs them. A gallery mosaic first, because a charter is sold on the interior and one exterior shot does not show a cabin. Then the specification strip — guests, cabins, crew, length, built and refit — as one row, because those six numbers are the filter someone has already been using and they should not have to hunt for them again. Then a sample itinerary, day by day, because "seven days from Marmaris" is an abstraction until it is a list of bays.

The enquiry card stays beside all of it. It carries the weekly rate, the check-in and check-out dates, and a total — one week, plus VAT at 20%, as a figure rather than a footnote. A price with the tax hidden underneath it is a price the reader has to redo, and someone comparing yachts is going to redo it wrong.

Then the page had to stop moving. Content that arrives after first paint pushes everything below it down, so a thumb aimed at the enquiry button lands on whatever slid into its place. That is a conversion bug wearing the costume of a polish item, and it is worst on the device where the target is a thumb rather than a cursor. The same pass got the page working at phone width, which it had not been.

The fleet search

263 yachts, filtered by price, length, cabins, guests, type, destination and dates, then sorted. The search and the filters were returning the wrong yachts.

The index is not in the browser. It is Elasticsearch, on the backend, and the frontend's job is narrow: turn what someone clicked into a query, send it, render what comes back. So a filter returning the wrong yachts is not something the frontend can settle on its own.

I worked it through with the backend team until the filters returned what the panel claims. The alternative was available and worse — filter the fetched page of results in the browser, and the grid would agree with itself while disagreeing with the fleet.

The pages Google sees

Around a hundred pages exist for search: destination guides, yacht-type pages, cost and booking guides. They are the top of the funnel. Someone reads one of those before they ever reach a yacht page.

Most of my work here arrived as QA tickets against page speed and on-page SEO. None of it is clever work. All of it is the kind that fails quietly: nothing throws, no page breaks, the score just drops, and you find out because somebody ran a report.

Speed carries the same weight here as content does. A landing page that takes its time is a page someone leaves before they have seen a single yacht, and the enquiry never happens on any of the pages downstream.

Working on a site that is already selling

None of this shipped on a quiet branch. The site was live and taking enquiries for the whole seven months, which is what decided the order: the yacht page first, because that is where the enquiry is sent, then the search that feeds it, then the pages that feed the search.