How to build an optimized local business website with AI that converts

It's happened to all of us who build websites.

You talk to a potential client who runs a local business—the kind people visit in person or that serves a limited geographical area—and they come out with: “Just a simple little website, so people can call me or message me on WhatsApp.”

A simple little website. Sure.

Obviously, an e-commerce site with thousands of products or a SaaS is much more complex. But if a business wants to attract customers through its website (usually with little or no advertising budget), believe me, there's nothing simple about it.

Before doing anything, you need to understand what the company offers, find out how customers search for it, decide which pages it needs, write the copy, choose images, build forms, track leads and make sure everything works on a phone.

If you also want to publish it in several languages, the number of decisions multiplies.

I've built quite a few. And every single one—every single one, without exception—has exceeded its targets and generated more leads than originally agreed. That's why I know what I'm talking about.

Until now I had a system, including the essential marketing work, which I almost always implemented in WordPress, for obvious reasons.

But AI has arrived. And it makes things easier that used to take ages, were practically impossible to manage, or simply weren't worth the effort. Now they are. That's why I built my latest website, for the transport company Rondabus, without a CMS, using a development framework, Astro, which I hadn't heard of until ChatGPT recommended it after I explained what I wanted.

I think it was an excellent decision, because it focuses on something I've always believed: for corporate websites that barely change for months and aren't used to publish new content, static HTML has three clear advantages:

1. Faster.
2. More secure.
3. No paid hosting required.

I'll go into more detail when I discuss the technology stack, in case that third point surprised you.

After all, having a corporate website with everything needed to generate leads (form, email, phone and WhatsApp) while paying only roughly €3–10 a year for the domain sounds pretty wonderful.

And it is.

In this guide I'll walk you through the process so you can reproduce it yourself. Apart from the domain, all you need is a paid ChatGPT account to analyze, structure, write, translate and review, while Codex works on the code..

Of course, you can use other tools instead. I mention this especially if you're also paying for Claude, because combining ChatGPT as analyst with Claude as developer is even better.

Now that the requirements are clear, here's the step-by-step process.

1. Understand the project and define everything before you start

First, the client needs to explain:

1. What the business does.
2. What services it offers.
3. Who its target audience is.
4. Which areas it actually serves.
5. Who its competitors are.
6. What sets it apart from them.
7. What evidence it can show.
8. What actions you want visitors to take on the website. In other words, how the digital channel will generate business for the company.

Alongside this information, you, the client, or both of you will define:

• The domain.
• Contact channels (phone, WhatsApp, email, form…)
• Planned languages.
• Copywriting.
• Photographs or images.
• Whether content will be published regularly.

Both you and the AI will need all of this.

We distinguish three types of decisions here:

1. Those relating to business determine what is sold and to whom.
2. Those relating to content and design determine what is communicated and how it is presented.
3. The technical decisions determine how the website is built, published and maintained.

Once you've defined all that, record those decisions in a brief and a product requirements document (PRD) before you start building pages. Giving ChatGPT these documents means you don't have to explain in every conversation which domain is correct, which pages have been approved or where the phone number and email address came from.

The technology doesn't matter at this stage. This approach works with WordPress, Astro or any other system: keep decisions in one clearly defined place and business data in another source.

Deliverable

A short brief and a complete PRD, including approvals, pending decisions, conversion goals, available assets and responsible people.

Whenever a decision changes, update the PRD yourself or ask Codex to do it for you.

2. Create mockups to settle on a design

Before asking Codex to write any code, it's better to prepare two or three proposals so you can compare different approaches. You don't need three finished websites. Usually a homepage or a service page for each proposal is enough to get a feel for the project's overall look and feel.

But you should also show the mobile version to avoid surprises.

That's the first thing we'll ask Codex to do.

As a starting point, we explore three concepts for a service page. They can be light or dark, or use different colours and styles. Choose whatever you think suits the project, but ask for three. Two is too few; four or five starts to be too many.

Once you've got the options side by side, check whether each proposal includes the necessary sections, whether the copy is correct (yours or ChatGPT's), whether the phone number or WhatsApp appears properly, whether the form asks only for necessary information, whether the images accurately represent the service, etc. In short, whether it meets the essential requirements of CRO..

Once you've refined the essentials through as many iterations as needed, you can show them to the client, get their opinion and explain which of the three you think is best. But make sure that what you show is as close to the final design as possible, not just a rough approximation. Clients don't necessarily have the same experience of abstracting website designs as you do.

Deliverable

A mockup with an approved visual direction, desktop and mobile versions, a list of common patterns (header, footer, icons, hero section with form…) and a list of details that must be respected during implementation.

3. Carry out some guerrilla market research

You don't need a hundred-page study to decide the initial structure of a local website. You need enough data to avoid choosing pages on gut instinct—yours or, worse, your client's. The analysis has two parts: demand and competition..

Demand analysis: what users search for, how often and where

The first thing to establish is whether there's already demand for what your client offers, or whether you need to create it. And particularly with local businesses, how much demand exists in their service area..

For that, here's a complete step-by-step article on demand research for e-commerce, but I'll summarize it and adapt it to a local business website below.

Make an initial list of services using the words a customer would use. Add variants, needs and geographical modifiers. For example, in my case:

• Bus hire.
• Bus hire Ronda.
• Wedding transport.
• Wedding bus Ronda.
• …

You get the idea, right?

Then check which searches show an intention to hire, which seek information and which involve services that should share a page. For example, “bus hire for weddings”, “coach for wedding guests” and “transport for a celebration” all address a similar need. You don't need three pages just because there are three phrases. In contrast, “school transport” and “airport transfer” have sufficiently different audiences, conditions and questions to deserve separate pages.

At this initial stage, while you're defining the website's structure, focus only on searches with commercial intent. Save the rest for the blog, if you ever have one.

Use the Google Ads Keyword Planner for estimates, restricting the geographical area. That gives us an idea of the traffic we might reach, bearing in mind that a range of searches isn't the same as the organic visits we'll receive—only some of those searches turn into visits. With that and an estimated conversion rate, we can project the number of leads we could attract each month.

Competition: who you're up against

Again, here's an article where I explain in detail how to carry out competitor analysis for e-commerce. It's a little old and some things have changed, but the fundamentals haven't.

For a local business, search as a customer would from the relevant areas, then record which businesses appear in organic and local results. Look at their:

• Services.
• Copy, CTAs and content.
• Website structure.
• Geographical coverage.
• Calls to action.
• Contact methods.
• Online reputation (ratings in directories such as Google Maps or Trustpilot).
• Lead magnets, if they have any (usually not, since they won't be doing email marketing).
• Prices.

The idea isn't to copy whoever tops the list. The comparison should help you spot unanswered questions in your content, clarify your value proposition(s) and identify opportunities your business can genuinely deliver on.

If you can't access a competitor's financial data , don't make it up. Ask ChatGPT, perhaps using Deep research..

Deliverable

Two things:

A table of keywords, grouped by tentative target URL (usually the homepage and service pages), geographical area where relevant, commercial priority, visible competitors and conclusions. Its purpose is to make decisions about the website, its structure and the content (especially headings) of each page.

Alongside that, we'll also produce a document collecting all the good ideas from competitors that could apply to my business and its website.

4. Define the website and page structure based on demand

Now turn those tentative keyword groups into an actual page map. For each proposed URL, note:

• Which need it meets, whom it targets and which service it represents.
• Which action it should generate (form submission, phone or WhatsApp click, appointment booking…).
• What content it needs.
• Whether I can obtain genuine testimonials.
• Which pages will link internally to it.
• Which geographical area it will target (perhaps just one, or perhaps it makes sense to repeat a service page because I attract customers in two different cities or countries).

Also decide which pages should be indexed. Or rather, work backwards: which ones should not be indexed. For example, legal pages and pages that duplicate content (About Me and the homepage).

For content purposes, another important point is that if the business has a Google Business Profile, the information there (name, services, contact details, opening hours and actual service areas) must be exactly the same as on the website.

Deliverable

A page map with:

• URL.
• Keywords it targets.
• Page-specific content decisions.
• Whether or not to index it.

5. Finalize requirements and choose the right technology

Before developing anything, all the decisions we've made must become a working document: a new, complete version of our initial PRD. The document should allow another person—or the AI in this case—to understand what to build and how we'll know it's finished.

Generally it's more convenient to keep all this information in a ChatGPT project and ask it to draft the document, prompting you for any missing information it needs. Then you just review and edit it. Much quicker.

With all this information in hand, it's time to choose the technology. For this type of website, I'd consider two systems: the Astro framework (here are its advantages and disadvantages) or WordPress. This article offers a head-to-head comparison of the two, explaining why I currently prefer Astro for these projects.

The winning combination is the one I use, and it's the one I'll follow in this tutorial::

• Astro to generate the website.
• GitHub as the code repository.
• Cloudflare for publishing (not essential, but easier if you've also bought the domain there).
• Zoho Mail for the corporate email and the form API.

That said, if a business has a team that needs to edit lots of content frequently through a dashboard, WordPress may be a better starting point.

Besides choosing the technology, now's the time to organize your source materials. Create a folder on your PC with several subfolders, for example:

• Original client materials.
• Your own materials (demand research, mockups, PSD files, copy…).
• Code.
• Final website assets (what will be uploaded to Cloudflare: mainly HTML, CSS, JS and images).
• Production secrets (passwords).

Not all these materials belong in the repository: only what's essential to rebuild the website, without passwords or huge original documents that we merely keep as working sources.

Once this structure is in place, it's time to create a project in Codex, separate from the one we created in ChatGPT. These are two separate projects that will share materials such as the PRD. From now on, imagine you've got two people working for you:

1. ChatGPT: the analyst, who designs the system according to your specifications and suggests solutions.
2. Codex: the developer, who builds the website according to the analyst's instructions.

To create the project in Codex, simply:

1. Create a new project in the app.
2. Give it a name.
3. Share the root folder of the project we created on our PC.
4. Tell it where the PRD is and ask it to evaluate everything before starting.

To finish this step, we just need to decide a few final details before development:

• How changes are reviewed before publication (should Codex do it or would you rather review them manually?).
• How the website gets published (does Codex commit to GitHub and then deploy to Cloudflare, or do you do it manually?).
• Whether the website will have several languages, and which one to start with.

Once you've settled those details, ask it to add those decisions to the PRD. Since it has permission to write to the folder, it will make the necessary changes in the document. From now on, here's the workflow we'll follow:

1. You think about what you need. You're the project owner.
2. You tell ChatGPT and together you assess each point and any outstanding questions.
3. Once everything is clear, ask ChatGPT to prepare the prompt for Codex.
4. Paste it into Codex, which will execute it.
5. Review what Codex has done and iterate if necessary.
6. Move on to the next development task.

From this moment on, your only job is to think, decide and define. Your analyst and developer will build the website.

Deliverables

• Approved pre-development PRD (it may change as the project progresses).
• Folder with the repository structure.
• Publication and testing plan.

6. Write the copy

If you haven't already, now that the website structure and project are set up, it's time to start creating the content for each URL.

The homepage should explain the overall offer and guide visitors to the services. Each service page must describe what's offered, for whom, in which situations, what questions customers tend to ask and how to get in touch. SEO copy isn't a substitute for copy that's useful to people: when both are planned well, they work together.

Use AI to prepare drafts with context. Tell it:

• The service.
• Your unique value proposition.
• Audience.
• Geographical area.
• Tone.
• Real FAQs.
• Any testimonials you have. If the business has a Google Business Profile, you may be able to draw good reviews from it.

Iterate and edit what it gives you until it's ready to publish. Then think about how to distribute it across different sections, or ask ChatGPT for suggestions. Some sections may recur throughout the website (a form, a map, general advantages). Don't worry about that yet; we'll deal with it in the next step.

Here's a sample prompt for a service-page draft:

Write the [servicio] page for [negocio] in [zona]. Unique value proposition: [propuesta]. Audience: [audiencia]. Main intent: [necesidad]. Testimonials: [lista]. Common questions: [lista]. CTA: [acción]. Use a [tono] tone. Suggest a structure, copy, SEO metadata and schema. Flag any claims that need evidence, and don't invent figures, reviews, vehicles or coverage.

Create the content for every page, one at a time.

Deliverable

Approved page briefs containing the content: copy, CTAs, metadata, supporting evidence and visual assets. You can build the homepage and one representative service page first to check the system works before rolling it out to the remaining services and contact pages.

7. Separate reusable components

With the mockups and page briefs in front of you, identify what genuinely repeats: header, navigation, footer, buttons, form, benefit cards, image sections, final CTAs, notices…

The reason is that we'll create reusable components for these elements, so if the phone number changes, we only change it in the component and the update appears across every URL. Obviously the header and footer are reusable, but there may be more.

You may also want every service page to share a design or structure. So separate the structure from the data. Examples:

• A service page template can assemble common sections without imposing the same text on every page.
• More specifically, a benefits component can retain its layout while changing the title, explanation and icon.

Run a practical test before replicating the pattern: ask ChatGPT to write the prompt for Codex to lay out the homepage and a service page, compare them with the mockups and adjust both the individual content and shared components.

Check how they look on desktop and mobile. Once everything's right, extend the system to the rest.

Deliverable

Homepage and one service page with their layouts completed.

An inventory of components, the data each receives and the pages that use them.

8. Prepare the images for production

Right, after the copy comes the imagery.

Ideally the client will have supplied some decent photos you can use. In practice, that rarely happens. Fortunately, if Photoshop isn't your thing, ChatGPT is your friend, and its image creation and editing system is very, very good. So let's get to it.

Don't overcomplicate things: one to three images per URL should be plenty. Some will probably be reused. Ideally, though, the first image—the header image—should be different on each page.

Keep the client's originals and, whenever you create a new image, save a high-quality master in folders you won't upload to the repository.

Then ask ChatGPT to tell Codex to adapt each image for its place on the website, and to:

• Generate versions in suitable dimensions and formats, usually .webp for photographs and SVG for icons.
• Define responsive sizes and avoid sending mobile users a file intended to fill a large desktop screen.
• Reserve space for it so the page doesn't jump as it loads. The main image may need higher download priority, whereas a picture far down the page can wait.
• Useful alternative text describes what the image communicates; even better if a relevant keyword fits naturally.

Deliverable

Final images for the website.

9. Create the icons

Probably the hardest part to optimize on websites with lots of them (more than 20 or 30).

The trouble is, it's hard to create variants for all of them in a consistent style, particularly within a single icon sheet. You end up tackling them one by one, and that takes time.

And then comes something even harder: converting them to SVG and making them look right. That's why my advice is that if you have to use manually cropped PNGs or cut them from an icon sheet made in Photoshop, go ahead. You won't achieve 100% optimization, but you'll save an enormous amount of time. I know from experience.

For example, with Rondabus I tried several approaches because the first drawings didn't match the references: some were too simple and others looked like a different scale even though they occupied the same box. I even explored crops and PNGs from the approved sheets, but the solution that made it into version 2.0 was the original SVGs displayed at a larger size..

To carry out the process:

1. First identify where each icon appears and what it means.
2. Group recurring icons together.
3. Keep one master for each drawing or icon sheet.
4. Prepare a preview in the actual contexts: hero, service card section, benefits list section, contact…
5. Adjust the optical size without distorting the shapes: two icons with identical file widths can look very different because of the whitespace around their drawings.
6. Validate a sample on an important page (homepage or services) before changing every page. If an attempt doesn't reproduce the mockup's style properly, go back to the reference and reject it.
7. Apply it to the remaining pages.
8. The file format is an implementation decision; visual quality and consistency are what users will notice. And those matter most.

Deliverable

Approved set of icons and master files.

10. Build the website in stages

Once the homepage and service-page pattern are approved, build the remaining pages and review them individually. Sharing a template doesn't mean they'll all work visually: headline lengths, photographs, number of benefits, button labels and audience needs all vary.

Check desktop and several mobile and tablet widths. Put yourself in the user's shoes, compare every page against the mockup, and test what a static design can't show:

• Dropdown menu.
• Links.
• Front-end form validation.
• Images and icons loading.
• Long content.
• Line breaks in headlines.
• …

It's worth saving code checkpoints whenever a stage involving several changes is approved. Ask ChatGPT to arrange that while you're refining things.

Deliverable

Completed front-end pages (the form still needs validating, if you have one).

Checkpoint for the completed front end, website version V1 (one language). If you consider your website finished at this point, skip to section 17 to publish it online.

11. Set up a form and other contact methods

If you've read my articles about Astro, two things should be clear:

1. You're publishing HTML files.
2. To a server without a server-side language (PHP, Python).

That has many advantages and one drawback: you can't submit forms directly.

There are several solutions, including:

• Use paid Cloudflare services.
• Use an email provider (free or paid) and integrate the service via API.

In my case, since I generally set up the project's email too and use the free version of Zoho Mail, I prefer using that service to send messages generated by forms rather than adding another provider.

It's a little complicated and requires several steps you'll have to complete manually, so ask ChatGPT to guide you step by step. Above all, don't upload secrets to the GitHub repository. Cloudflare has somewhere to store them.

Once it's set up, fill in the form correctly and incorrectly to make sure validation and submission both work.

If you haven't already, now's also a good time to test the phone and WhatsApp links on a real mobile phone, if you've added them—as you almost certainly should.

Deliverable

Form tested and working end to end.

Checkpoint, website version V1.5 (completed with a form and one language).

With that, apart from publishing the website (step 17), we'd have finished the essentials for any local business website. But the next steps are HIGHLY RECOMMENDED if you want to attract actual customers.

12. Track contacts and configure consent

We'll begin the optional steps with something fundamental: measurement.

What do we want to measure? Just the essentials:

• Conversion events.
• Traffic.

Why?

To find out where sales come from, especially if we plan to pay for advertising to land our first customers (you should definitely consider it).

So first, define the analytics plan and the business events before installing anything. They'll be very straightforward:

• Phone contact.
• WhatsApp contact.
• Email contact.
• Form contact.
• Appointments booked in the calendar.
• Subscriptions (to a newsletter, if you have one).
• Clicks to view the address on Google Maps.

And that probably covers every event you'll need to track on this type of website.

Decide which ones apply and ask ChatGPT to provide:

• The event name following Google's recommended naming conventions, because I suggest using Google Analytics 4 to track them.
• Event trigger condition.
• Additional parameters (where appropriate).

The system works as follows:

A website visitor triggers an event > Google Tag Manager captures it > GA4 stores it so you can view the data.

Sign up for both GA4 and GTM with your Google account and, while you're at it, GSC too, which we'll use later for SEO.

If your business is in the European Union, tracking also depends on privacy decisions. That's why you should ask ChatGPT to implement the advanced Google Consent Mode v2, with an option to reopen preferences. It will create the familiar cookie banner.

Once that's defined, ask ChatGPT to have Codex give you a JSON file containing the container to import into GTM. The AI will ask for the relevant IDs for your GA4 and GTM accounts and provide a small file with everything ready to import.

All that's left is to test each event in GTM's preview mode before publishing the container and starting to collect real data from your website.

Deliverable

The measurement plan and working GTM and GA4 implementations, with consent tested if applicable.

13. Finish the technical SEO and publish the first version

If you're working on local SEO, as you should be, it's time to run Screaming Frog and check for errors. Ask ChatGPT to have them fixed.

Connect the website to your Google Business Profile. Review the name, categories, address or service area, phone number, opening hours, photos and services without making up locations.

Also, in GSC (Google Search Console), submit the generated sitemap . If you don't know the URL, ask Codex directly. After a few days, check whether the important pages can be crawled and indexed.

Deliverable

A website free of technical SEO errors, with verified URLs and sitemap, and the correct canonical domain.

We could call this version V2..

14. Decide whether expanding the website into other languages is worthwhile

Now we reach the final part of the process: translating the website into other languages.

Before deciding, confirm:

• Which audiences you want to attract.
• Which language you'll serve them in.

Offering a massage to a Norwegian in Málaga without speaking their language isn't the same as offering legal services. You might also attract Japanese people looking for a taxi in Ronda, while making it clear that you can only serve them in English.

What's more, a new language means translating content, menus, forms, metadata, schema and future updates. It's not just a button with a flag.

Once you and ChatGPT know which languages you want on the website, establish:

• The source language, which is the one already on your public website.
• The languages to translate into.
• Which pages are translatable—not all of them are (for example, the 404 error page or legal pages).
• The URL policy. Decide whether slugs are translated, how equivalent pages are linked and what happens when a translation is missing.

The architecture should identify each page with a language-independent stable code, so the selector can go to the equivalent page and the website can generate hreflang relationships without having to guess based on the visible title.

All of this must happen before translation.

Deliverable

Translation plan.

15. Separate export, translation and integration

The process that works best for me is to split the work.

1. Codex inspects the project and prepares a text package with stable identifiers, source text, context, target language, placeholders, links and protected terms. It will usually give us a JSON or XML package.
2. ChatGPT translates these packages, reviews the values and returns the translated files.
3. Codex integrates these files and validates the pages.

This separation means you can change translators (even use a human) without making them understand the code or forcing the developer to guess what each sentence means. Of course, ChatGPT's review isn't a substitute for a linguistic review by a certified translator.

Export prompt:

Inspect the project and prepare a translatable inventory for [idiomas]. Include visible text, navigation, forms, metadata and slugs. For each unit, provide a stable ID, source text, context, placeholders, links and protected terms. Do not translate or modify the pages yet. Report ambiguous strings and content with no equivalent.

Translation prompt:

Translate only the package values into [idioma y variante]. Audience: [audiencia]. Tone: [tono]. Glossary: [términos]. Preserve IDs, structure, order, placeholders, proper names, links and code. Flag outside the package any sentences requiring a business decision or native-speaker review.

Integration prompt:

Import these approved translations into the project. Check IDs, placeholders, protected terms, slugs and equivalent routes. Do not publish a language with mandatory text missing. Run the translation audit, project checks and build; report any differences before deployment.

Deliverable

Multilingual website, not yet reviewed.

16. Audit each language as a complete website

Once the translations are integrated, open the pages: a valid file can still produce an overflowing menu, an excessively long CTA or a notice that covers the form. Review every URL in every language on desktop and mobile.

For SEO, check (yourself or with ChatGPT):

• <html lang>.
• Title.
• Description.
• Localized URL.
• Self-referencing canonical.
• Hreflang relationships between equivalent pages.
• Sitemap of indexable URLs.
• The language selector should keep visitors on the current page when an equivalent exists.
• Also check footer links.
• Forms and error messages.
• Image alternative text.
• Structured data containing text or URLs.

Iterate as needed until everything is polished.

Deliverable

Complete multilingual website, version V3.

17. Publish an identifiable version and verify production

Whether you're coming from step 10 (V1), 11 (V1.5), 13 (V2) or the previous one (V3), what we've got is a website built in a test environment. We still have to deploy it to production. And that's what we'll do here.

Here we'll ask ChatGPT to tell Codex to publish the build to Cloudflare.

To do that, Codex will:

1. Log in to our GitHub account.
2. Ask us to select or create the right repository.
3. Log in to our Cloudflare account.
4. Ask which domain to publish to.
5. Publish the latest version of the website.

And all we have to do is check that it looks the same as in our test version.

The website will be finished.

Deliverable

Full version of the website, published.

18. Turn the project into a repeatable method

This is even more optional, but highly recommended if you want to apply the process to another business's website.

Just ask ChatGPT to create a Skill covering the whole process you've followed. That way you won't have to remember every step from last time or come back here to read the tutorial. Your ChatGPT will have it safely stored and Codex will have it installed under the hood.

That way the next local business website you build will be much quicker.

Pretty cool, right?