A building from 1828, online properly.

The brief

One venue doing four jobs.

The Star Bar building was raised in 1828 out of convict brick, when Launceston was twenty-two years old and Tasmania was still called Van Diemen's Land. Today the same building runs a public bar, an open-air rooftop, a restaurant with a wood-fired oven that has been lit since 1991, and boutique rooms upstairs. Four businesses, one front door, and the site had to make that legible rather than confusing.

The old site was WordPress, still printed a retired phone number, and published no menu at all. The brief was a replacement that opens fast, publishes every price, and reads correctly to a person, to Google, and to an AI assistant being asked where to eat in Launceston. Everything below is hand-written. No theme, no page builder, no CMS, and no build step.

The hard part

The code was the easy half.

Nearly every difficult hour on this job went into working out what was true. A pub that has been trading since 1828 leaves a long trail across the internet, and most of it had drifted. The venue's own published information contradicted itself, the directories contradicted the venue, and the first build repeated some of it because it was the best evidence available at the time.

The menu prices were the delivery menu, and arithmetic caught it

The first build shipped 24 prices taken from the only source that had any. Something looked off, so they were tested against round numbers. Three came out at exactly 1.15 times one: fish $35.65 from $31.00, Hawaiian $26.45 from $23.00, kids ham and cheese $20.70 from $18.00. Two more matched the Uber Eats listing to the cent. They were delivery prices carrying a platform mark-up.

They could not simply be divided back. Only 6 of the 20 standing dishes came out round at 1.15, and $19.90 and $29.80 are not round in either direction. So all 24 were pulled rather than guessed, and the restaurant page ran without prices until the venue's real counter menu arrived on 6 August. That document turned out to be a different menu entirely: 55 lines across 11 sections where the site had 24 across 7, with Desserts, Sides, Sauces and From the grill missing altogether.

Every price is written down four times, so a script checks all four

A price on this site exists in the visible menu, in the structured data Google and Bing read, and in both of the llms files an AI assistant reads. Four copies that must agree, and the obvious failure is someone updating one and not the others. So menu-parity diffs all four in both directions and fails loudly. The same pattern covers the FAQ, the opening hours and the citations.

Withdrawing one claim can touch nine places

When the client stopped serving breakfast, that single sentence was wired into the trading-hours tables on two pages, the opening-hours structured data, the FAQ in both its visible and machine-readable forms, both llms files, the footer of all ten pages and the handover notes. Removing tea and coffee from the rooms took nine edits of its own.

Deleting a claim does not always end it. Tea and coffee is a standard field on the booking-site listings, so it would keep coming back from Tripadvisor and Booking.com regardless of what the site said. That is why the site carries an explicit list of its own client's published facts to disbelieve. It now runs to seven entries, including the retired phone number, the live music timetable that was never real, and a flat statement that every price in the wild is a delivery price.

One "obvious typo" was corrected, and the correction was wrong

The bar page said the venue had served Launceston since 1838, against 71 occurrences of 1828 everywhere else. An SEO pass changed it on the reasoning that a lone outlier is usually a mistake. It was not. The building went up in 1828 and the liquor licence came ten years later, and the client confirmed both the same day. It was reverted, and the llms files now state plainly that the two dates are different and both correct, so an AI assistant does not helpfully smooth them into one.

What went wrong

Three things that did not work first time.

Every build has these. Most case studies leave them out, which is why most case studies are not much use to anyone deciding who to hire.

The mobile menu had never worked, on any version

Found on a real phone. Tapping the hamburger locked the page and opened a 96 pixel sliver showing one nav item. The cause is a genuine trap: an element with a backdrop-filter becomes the containing block for anything positioned fixed inside it, so the header's frosted-glass effect was quietly capturing the navigation and sizing it against a 74 pixel header instead of the screen.

A seven-pixel overflow that could not be reproduced

Reported from a phone as a white line down the right edge, and invisible in testing because the wrong element was being measured. Below 347 pixels the header lockup needs more room than the viewport has: the wordmark cannot shrink, and the button and toggle together need 182. Fixed by splitting the button label so it drops from about 122 pixels to 59 on the narrowest phones. The breakpoint is 340 rather than the rounder 360 because clipping actually stops at 344.

One element cost a quarter of the performance score

Mobile Lighthouse came back at 76. Everything was fast, first paint 1.4s and zero blocking time, but layout shift scored 9 out of 100. All of it traced to a single node: the navigation painted in flow, then collapsed once the deferred script parsed and removed the no-js class. Moving that one flip into an inline head script took the shift to a stable zero and the score to 99.

Worth adding, because it is the more useful lesson: an earlier round of measurement had produced a perfect 100 across the board and it was wrong. Those numbers came off a local rig, where a zero-latency connection flatters the simulated throttling. Measured against the real host the home page reads 100, 82 and 100 across three consecutive runs. The perfect score was retracted rather than quietly kept.

The real problem

The dead website was beating the live one.

The site went live and nothing happened. Not slowly, not partially. On 11 August, a week after launch, a Google search for the exact string starbarcafe.com.au returned six results from the old dead domain and not one from the live site. A query that spells out the new domain by name could not find it.

It got worse the closer you looked. A URL on the old domain that returned a 404 held second place for "rooftop bar launceston" while the real rooftop page sat around twelfth. Google's AI summary was citing three old-domain pages and repeating the exact claims the rebuild existed to delete: breakfast from 7am, live music every Friday and Saturday, a nightclub. Brand searches were still quoting the retired phone number.

The redirect table had been written correctly on day one, ten legacy URLs mapped to their new homes. It had never fired once. The old domain was still pointed at the registrar's parking nameservers, so requests never reached the hosting where those rules lived. The rules were perfect and unreachable.

Then the old domain changed shape, and the middle state was the dangerous one. It stopped returning 404s and began redirecting every path to the home page instead. To a person that looks fixed. To a search engine it is a soft-404: sending /rooftop-bar/ to the home page does not tell Google that the rooftop page moved, it says the rooftop page is gone and here is the front door.

The fix was one checkbox

After two full audits had both recommended rebuilding it as a hosting alias, the actual cause turned out to be a single unticked box on the registrar's domain forwarder, labelled "retain source path". With it off, a wildcard forward collapses every URL onto the destination root. Support ticked it, and it propagated in under twenty minutes against the one to two hours quoted.

All ten legacy URLs now resolve correctly, verified end to end. The rooftop page, the menu, the bookings link, the old about page: each lands where it should. It cost more hours than any design decision on the project, and the entire remedy was a checkbox at a company neither of us writes code for.

Still open

What is not finished.

Two things sit outside the website and cannot be fixed by changing it, so they are listed here rather than quietly dropped.

• The Google Business Profile is filed as a hotel. A three-star hotel category on a venue whose main trade is the bar, which locks it out of the local results for every bar and pub search in the city. It also advertises a swimming pool the venue does not have, and publishes a closing time that contradicts the site. Only the owner can change the category.
• Analytics is installed and measuring nothing. The container is on all thirteen pages and is empty, so until a tag is published inside it there is no traffic data at all. Before this the venue had none of any kind, so there is no history to compare against yet.

The search recovery is also still in progress by definition. The redirects were only corrected on 12 August, and Google has to re-crawl the old domain before the authority it is holding moves across. That is measured in weeks, not hours.