How I built a body shop’s site in Uvita around WhatsApp quotes

WhatsApp is the main button on this site. It sits in the first screen next to the phone button, and a floating copy follows visitors down every page. The closing section of the home page asks for exactly that: send a photo on WhatsApp.

A form still exists for people who prefer typing. When someone sends it, the server is set up to email the request to the shop, and WhatsApp then opens with the text already written. That means two channels to check every day.

If a visitor arrives from a tagged campaign link, I keep those tags for 90 days and add them to the request, so the shop can tell which campaign sent the message. I also set up five named events in the site’s analytics: a WhatsApp tap, a phone tap, a form sent, a form error and the 3D fallback. Visitors who send a Do-Not-Track signal are skipped. The events are there so the owner can compare which buttons people use.

Spanish is the default. If a visitor’s browser is set to English, the site sends them to /en instead. Every page has its own address in each language, and each one points to its twin with a hreflang tag, a small label that says “this page also exists in English, here”. It helps Google understand that the two belong together.

Today English text covers the services and the guides, plus the FAQ, about, contact and privacy pages. Translation is the part owners underestimate: every later text change has to be made twice. So I kept page text in one set of files per language, and the shop’s facts, such as hours, services and areas, in a single data file that feeds the pages, the sitemap and the structured data.

A second language is a commitment: budget for every later text change, not just the first translation.

The home page opens on a 3D car, and the light on its paint follows the cursor. A body shop sells finish quality, and a glossy car shows it before any sentence does. The model file is small, under 70 KB, and it downloads only when needed, so the text does not wait for it.

There are two trade-offs. A 3D scene asks more of a cheap phone than a photo does, and it is one more part that can fail. If your customers mostly use old phones, I would choose a photo.

Images are where sites get heavy. Two page images weighed 961,522 and 1,180,514 bytes, around 1 MB each. I re-encoded them smaller, still as AVIF (a compact image format), and they dropped to 33,978 and 66,610 bytes. Next.js also serves AVIF or WebP to browsers that support them.

Decide the limit before the photo shoot, not after the page feels slow. It is far easier to shoot for a limit than to rescue a heavy picture later.

The brand reel is the heaviest asset: four files of 5.5 to 6.5 MB. The player never starts on its own, and it gives phones held upright the vertical version, so they skip the wide file.

Beyond the home page I built five service pages, four town pages for Uvita, Dominical, Ojochal and Bahía Ballena, and four guides. Each carries structured data: labels in the page code that tell Google it is a service, a list of questions or an article.

The guides answer the kind of question a customer asks at the counter; one, for example, explains when a frame really needs straightening.

I also published plain-text files for AI assistants and let their crawlers in through robots.txt. I cannot promise what that will do for the shop. It takes little effort, and the owner should decide whether to be found that way.

Any public form attracts bots, but this one has no CAPTCHA, the picture puzzle: a customer with a damaged car and a weak signal does not need one more hurdle. Quiet checks on the server stop simple bots instead.