I have spent more than 20 years working in digital marketing. I have been involved in websites since they were designed for monitors roughly the size of a microwave and built using tables nobody was allowed to touch.
I have watched SEO move from link farms and spun articles to useful content, technical quality and E-E-A-T. We are now moving into another phase where large language models can help us plan, create and improve the websites themselves.
Over recent months, I have been using several AI tools whilst rebuilding parts of the GrowTraffic website. I have also applied the same approach to work carried out on other websites.
This has not involved asking ChatGPT to ‘make me a website’ then accepting whatever emerged.
I use ChatGPT to help develop the strategy and prepare detailed briefs. Claude Code has handled much of the implementation. Grok provides a different perspective. Gemini helps check whether the overall direction makes sense. DeepSeek occasionally gives me another opinion.
More recently, I have started using Grok Build. It is not as advanced as Claude Code but it has made some surprisingly good creative decisions from instructions that were far less specific.
The result is an increasingly sophisticated workflow involving several models. That sounds rather grand. In practice, it sometimes involves me sending the same screenshot around until somebody explains why the thing I dislike looks wrong.
The short version is this: AI can help you build things you could not previously build yourself. It is not always quicker and it does not remove the need for experience, judgement or proper technical checks.
Used properly, it expands what you can create.
Used carelessly, it lets you make mistakes at a speed previously available only to really well-funded companies.
What Does Building A Website With AI Actually Mean?
Building a website with AI means using artificial intelligence to help plan, design, write, code, test or maintain a website. It can involve a conversational tool such as ChatGPT or an agentic coding tool such as Claude Code or Grok Build.
There is an important difference between generating a paragraph of homepage copy and allowing an AI agent to inspect a codebase, change files, run commands and deploy a working page.
The first is content assistance. The second is AI-assisted software development.
My process now covers most stages of the website project. I use AI to explore search intent, define the commercial proposition, structure the page, prepare content and develop the visual concept.
Another AI then implements much of that thinking. I inspect the result, share screenshots and ask for further analysis before the next round of changes.
I remain responsible for the final decision. The models contribute ideas and production capacity but none of them has to answer to a client when a form stops working.
That accountability cannot be delegated to a chatbot.
What Has AI Allowed Me To Do?
AI has enabled me to create website features I could not have built personally without considerable development support. That includes responsive layouts, bespoke visual components, interactive elements and technical fixes outside my normal skill set.
This is more significant than merely doing familiar work more quickly.
I understand websites, content, user journeys, conversion and search. I can normally explain what I want a page to achieve and why the current version is failing.
What I could not always do was translate that understanding directly into production-ready HTML, CSS and JavaScript.
Historically, a more ambitious idea would require a developer. I would need to prepare a specification, explain the idea, get a quote and wait for the work.
That process naturally discouraged experimentation. You do not commission five alternatives when every version carries a meaningful cost.
AI has reduced the distance between an idea and a prototype. I can now describe an unusual visual treatment, see it built and decide whether it works before committing substantial development time.
That has changed what I am willing to imagine.
It does not make me a software engineer. I would be suspicious of anyone claiming a few months with an AI coding tool had replaced years of engineering experience.
What it has done is give me access to more development capability. I can direct technical work more closely and understand more of what happens between the brief and the browser.
Which AI Tools Am I Using?
I do not believe there is one universally best AI for website development. Different tools are better at different parts of the process.
My current workflow is based on roles rather than loyalty to one particular company.
Tool Role In My Workflow What I Currently Find Useful
- ChatGPT Thinking partner Context, strategy, sense-checking, content and detailed briefs
- Claude Code Main development tool Advanced implementation, codebase inspection, debugging and controlled changes
- Grok Build Creative development experiment Bolder interpretations and more contemporary visual decisions
- Grok Alternative perspective Challenging assumptions and proposing a different direction
- Gemini Directional sense check Checking whether the plan makes sense and whether anything obvious is missing
- DeepSeek Additional opinion Occasional technical or analytical review
- Me Final decision-maker Reconciling advice, checking evidence and deciding what is implemented
This is not a democratic process. Five models agreeing does not make something true.
Models can share similar training data, repeat the same web conventions and make the same confident mistake.
The value comes from giving them different jobs then applying human judgement to their output.
Why Do I Use ChatGPT For Thinking And Briefing?
I use ChatGPT for most of the strategic thinking and briefing because it has the greatest continuity with me and GrowTraffic. It understands more of the business context than the other systems I use.
We have worked through GrowTraffic’s positioning, services, pricing, audiences, sales process and content strategy. It has also seen the evolution of the website and many of the decisions that sit behind it.
That accumulated context changes the output.
A model seeing one isolated page might suggest a perfectly reasonable change that conflicts with another page or misrepresents how we deliver the service. ChatGPT is more likely to recognise that connection.
It also understands how I tend to reach decisions.
I rarely arrive with a beautifully formed instruction. I normally begin with something like ‘this feels too centralised’ or ‘there is too much going on here’.
We then work through what that reaction means. It might be weak hierarchy, excessive symmetry, poor spacing or several messages competing for the same level of attention.
ChatGPT helps translate an instinctive response into a diagnosis. That diagnosis then becomes a brief another system can implement.
Familiarity carries a risk. A model that understands me can become good at producing the answer I am most likely to approve.
That is one reason I use other models for colder reviews. ChatGPT provides continuity. The others provide friction.
Why Is Claude Code Still My Main Development Tool?
Claude Code remains my main development tool because it is capable of working across an established codebase. It can inspect files, make changes, run commands and help diagnose technical problems.
Anthropic describes Claude Code as an agentic tool that can read a codebase, edit files and run development commands. That matches how I have been using it rather than treating it as a code snippet generator. Anthropic’s Claude Code documentation explains the broader capability.
Claude is particularly useful when the requested outcome has already been defined. If I provide a detailed brief with clear constraints, it can implement complex changes across a page or template.
It can also explain why a problem occurred.
On one responsive page, for example, the mobile layout was not stacking as intended because a later CSS rule was overriding the media query. Claude identified the interaction then amended the relevant code.
I have anonymised the page and implementation details here because this article is about the method rather than publishing a map of our website’s innards.
Claude is not infallible. It has told me a problem was fixed when the live page showed otherwise.
It can also make visually conservative decisions unless the brief is really specific. Its natural destination can resemble the agency design handbook from about 2017: centred heading, neat cards, gentle gradient and a button sitting politely underneath.
That is technically respectable. It is not always memorable.
What Has Impressed Me About Grok Build?
Grok Build has impressed me because it feels straightforward after using Claude Code and it has made some strong creative changes from relatively loose instructions. It is currently less advanced than Claude Code, but it sometimes interprets visual problems more boldly.
xAI describes Grok Build as a coding agent that can run interactively or through scripts and other agent interfaces. It remains a developing product but it is already capable of useful implementation work. The official Grok Build documentation provides the technical overview.
My comparison is based on my own use rather than a controlled benchmark.
Claude remains the stronger engineering environment in my experience. Grok Build feels more willing to move away from the predictable design patterns I have struggled to get Claude to abandon.
There have been changes I could eventually have achieved with Claude but only by describing the solution in painstaking detail. Grok Build reached a visually stronger interpretation with less direction.
That creativity comes with a caveat.
A tool that makes bolder decisions may also make decisions that do not fit the existing design system, CMS or maintenance process. A more exciting first result does not automatically create a better production website.
I can see a useful distinction developing.
Grok Build may help with creative divergence. It can explore what a page could become.
Claude Code may remain better for controlled convergence. It can take an approved direction then integrate, debug and maintain it within the wider project.
Why Do I Use Grok, Gemini And DeepSeek For Reviews?
I use Grok when I want a different perspective. I am not asking it to confirm the conclusion ChatGPT and I have already reached.
I want it to identify weak assumptions, challenge the proposed direction or suggest a materially different answer.
That lack of shared history can be useful. Grok may lack important context but it is also less likely to inherit every decision we have gradually stopped questioning.
Gemini performs a different role.
I often give it a proposed structure, screenshot or brief then ask whether we are broadly going in the right direction. I want to know whether something obvious is missing.
A cold review can discover that a detailed page still fails to explain who the service is for or what the visitor should do next.
DeepSeek is a less regular part of the workflow. I use it when another technical or analytical opinion may expose a gap.
The important discipline is giving each review a specific purpose.
If I simply ask every model to ‘improve this page’, each one will feel obliged to suggest more sections, more features and more work. AI is rarely short of ideas when it is spending somebody else’s time.
Why Did I Stop Using ChatGPT’s Earlier Development Tool?
I historically tried ChatGPT’s development environment but did not like it as much as Claude for the way I wanted to work. I moved towards Claude Code then did not return to make a fresh comparison.
That does not prove Claude is objectively better today.
AI products change quickly. A comparison made several months ago may tell you more about that particular version and user than the current state of the software.
I think it is important to be honest about that.
Online AI comparisons often involve somebody using each product once then producing a definitive ranking table. That is not how tools are normally adopted inside a business.
Familiarity matters. Existing workflows matter. The quality of the context and instructions matters.
I am now finding Grok Build relatively straightforward partly because Claude Code already taught me how to work with an agentic development tool.
The second tool benefits from lessons learned with the first.
Is Building A Website With AI Actually Faster?
AI is not always faster than completing a website task manually. The advantage may instead come from consistency, repeatability or access to skills the user does not personally possess.
There are plenty of changes I could make faster myself.
I could open Elementor, change a heading and publish it before an AI had finished explaining that it understood the task.
The overhead appears when I need to describe the change, wait for the system to inspect the project then check what it altered.
That does not make the process pointless. It means we need to measure the right thing.
The speed of one edit is not the same as the efficiency of maintaining an entire website. Nor is speed the only benefit.
AI may be slower at changing one heading but significantly better at applying an agreed convention across 30 pages without becoming bored or distracted.
When Is It Quicker To Do The Job Myself?
It is usually quicker to make small, obvious and contained changes manually. This includes correcting a typo, replacing a link, updating an image or adjusting simple Elementor content.
Delegating a four-minute task can easily create 15 minutes of explanation and checking.
The same applies when the desired result is easier to demonstrate through direct manipulation than language.
A person may drag an element slightly to the left without thinking about the underlying rule. An AI may interpret ‘slightly to the left’ as permission to restructure the entire grid.
Using AI for every task can become a productivity performance. We should not automate work merely because automation is available.
The useful test is whether the method reduces total effort, improves the result or creates something reusable.
If it achieves none of those things, do the job yourself.
Where Does AI Create Real Leverage?
AI creates genuine leverage when a decision must be applied repeatedly or when the implementation goes beyond the user’s technical ability. It is particularly good at systematic changes across related components.
We have used it to apply design conventions across sections, check responsive behaviour and recreate approved patterns without manually rebuilding every instance.
It can also provide a working prototype of an unfamiliar technical idea.
That allows me to judge the experience before deciding whether it deserves further investment.
Consistency is another form of leverage.
I may complete an individual task faster but introduce a slightly different spacing value or component structure because I am solving the immediate problem.
An AI working from a defined system can repeat the same rules more patiently.
Humans are often quicker at exceptions. Machines are often better at repetition.
The strongest workflow uses both accordingly.
How Do I Brief AI To Build A Website?
A good AI website brief explains the commercial objective, audience, content, visual direction, technical environment and constraints. It must define the problem before prescribing the build.
‘Make this look better’ is not a proper brief.
It invites the model to invent its own definition of improvement. That normally involves more cards, more animation or another gradient arriving uninvited.
We now develop the page strategy before asking a coding tool to implement it.
That process examines what the visitor needs to understand, which objections must be answered and what action should follow.
We also consider the visual idea.
A page should not simply inherit the standard sequence of hero, logo strip, three cards, testimonials, FAQ and enormous call to action.
The design should help explain the argument. A PPC page can behave like a commercial control system. A consultancy page can visually distinguish strategic input from implementation.
That creates direction rather than decoration.
What Should A Proper Website Brief Contain?
An AI website brief should cover purpose, audience, search intent, proposition, evidence, hierarchy and conversion. It should also specify the platform, components, responsive behaviour, accessibility requirements and testing process.
Our briefs increasingly contain:
The commercial purpose of the page
- The primary and secondary audiences
- The target search query and related user intentions
- The main proposition
- Supporting evidence and examples
- Required content
- Visual direction
- Approved calls to action
- Relevant internal links
- Elementor requirements
- Mobile and tablet behaviour
- Tracking requirements
- Structured data
- Performance considerations
- Protected elements
- Acceptance criteria
That sounds extensive because it is.
AI does not remove the need for a proper brief. It exposes how much interpretation used to be quietly handled by experienced designers and developers.
The brief also becomes a decision record.
Conversational AI does not always retain every earlier choice. A durable specification stops each new session from reopening matters that have already been considered.
Why Must You Say What Cannot Be Changed?
AI agents can interpret a narrow instruction surprisingly broadly. Ask for a mobile correction and the system may rewrite approved copy, alter the desktop layout or introduce a new component style.
The brief should therefore identify what is locked.
This may include existing content, desktop presentation, conversion tracking, approved calls to action or functionality that already works.
We increasingly use instructions such as:
Keep all approved copy
- Do not alter desktop behaviour
- Change only the specified section
- Do not introduce new commercial claims
- Preserve the existing form and tracking
- Use the current design system
- Do not deploy until the preview has been reviewed
This is ordinary change control.
The fact that the worker is an AI does not make scope less important. Its speed makes uncontrolled scope more dangerous because collateral changes can be produced rapidly and confidently.
Why Do I Share Screenshots And Live Pages With AI?
Screenshots and live pages anchor AI feedback in the actual website. They reduce the risk of the model reviewing an imaginary version based only on a written description.
I frequently send ChatGPT screenshots when something feels wrong.
My first reaction might be that the page feels too centralised, too dense or disconnected from the rest of the website.
A screenshot lets us examine the visual evidence.
The issue may be that every element has the same weight. The alignment may be too symmetrical. The page may lack breathing space or contain too many competing calls to action.
ChatGPT can translate that reaction into design language then help create a focused instruction for Claude Code or Grok Build.
The live page provides different information.
It allows us to consider navigation, page sequence, internal linking, responsive behaviour and how the page fits within the wider website.
Source code can reveal another class of problem. It may expose duplicated styles, unnecessary scripts or internal development references that have reached production.
The strongest review therefore combines the brief, screenshot, live website and underlying implementation.
No single view tells the whole story.
Why Must AI Work With Elementor?
An AI-built component must fit the website’s existing editing system. At GrowTraffic, websites are built using Elementor by default unless there is a good reason to use something else.
This is not because Elementor always creates the neatest possible code.
It is because our team and our clients can edit content, replace images and create pages without needing a developer for every routine change.
That operational value matters.
An AI coding agent may produce an elegant custom template containing hard-coded content. It can look excellent in the browser whilst being completely disconnected from Elementor.
Technically, the feature works.
Operationally, it has failed.
We therefore need to tell the AI that Elementor is part of the required solution rather than an inconvenience it may quietly work around.
This means respecting global styles, existing templates and the normal editing workflow. Custom code should enhance Elementor where necessary rather than replacing it by stealth.
Can Your Team Still Edit The Finished Website?
A website is not properly maintainable if every ordinary change requires the AI that created it. The team must remain able to update content through the tools they already understand.
We check whether headings, paragraphs, images, links and calls to action remain editable inside Elementor.
We also need to check that opening or updating the page in Elementor does not remove custom changes.
This is not a one-off test.
A component may begin as Elementor-compatible then gradually become more dependent on custom CSS or JavaScript as revisions accumulate.
That dependency should be intentional and documented.
Some features genuinely require custom development. A calculator, interactive visualisation or complex data tool may not sensibly fit inside standard page-builder controls.
In those cases, the question is whether the additional complexity is justified.
The best code is not always the cleverest code. For a working business, it is often the code somebody else can safely maintain next year.
How Does AI Improve Consistency?
AI can improve website consistency by applying explicit design and technical rules across many pages. This works only when the rules have been defined and stored somewhere reliable.
We have started developing a clearer visual language across the GrowTraffic website.
That includes approved spacing, card treatments, button styles, typography, process indicators and responsive behaviour.
An AI can inspect those conventions then apply them to another page. It does not become bored after the seventh component or decide that 37 pixels is close enough to the agreed 32.
The danger is assuming consistency happens automatically.
Each model can invent a new pattern whenever the brief leaves room. Repeated AI use without a design system may make a website less consistent rather than more.
The rules need to live in reusable components, CSS variables, templates and written guidance.
Otherwise, the system is relying on conversational memory. That is not a design system. It is an increasingly complicated anecdote.
Why Can AI Design Look Dated?
AI-generated website design often looks dated because models reproduce patterns that appear frequently across existing websites. Familiar layouts are statistically safe but rarely distinctive.
This explains the endless supply of centred heroes, glowing gradients, floating cards and three-column benefit sections.
None of those devices is inherently wrong. The problem appears when they are used without a connection to the content or brand.
We have had to push Claude away from overly symmetrical compositions.
A page can be technically polished yet still feel like it belongs to the previous decade.
Grok Build has sometimes been more creative from looser instructions. It appears more willing to use asymmetry, editorial composition and less predictable visual relationships.
That does not mean novelty should become the objective.
An unusual layout that confuses the visitor is not clever. It is simply expensive confusion.
The goal is meaningful distinctiveness. The visual treatment should reinforce the argument, improve hierarchy and help the visitor remember the page.
What Can Go Wrong With AI-Generated Code?
AI-generated code can work visually whilst remaining inaccessible, inefficient, insecure or difficult to maintain. It must be reviewed according to the consequences of failure.
A marketing section presents a different level of risk from checkout code, authentication or storage of personal information.
The more consequential the system, the more important qualified technical review becomes.
AI can duplicate CSS, add unnecessary JavaScript or patch symptoms instead of correcting underlying structures.
It may also report successful testing based on an incomplete check.
We have learned not to accept the model’s description of the result as proof.
The browser, source code, analytics and user journey provide the evidence.
How Does Technical Debt Accumulate?
Technical debt accumulates when each revision adds another local fix without cleaning the existing implementation. AI makes this easy because generating one more override is cheap.
A CSS problem may be corrected by adding a rule at the bottom of the file.
A later change conflicts with that rule so another more specific selector is added. Eventually the page works at one tested width but nobody can confidently explain why.
This is not unique to AI development.
The difference is speed. AI can create months of human-style improvisation during a particularly enthusiastic afternoon.
A completion pass should remove abandoned experiments, consolidate duplicated styles and simplify selectors.
Unused scripts should be deleted. Component names should make sense. Responsive rules should form a coherent system.
Refactoring is not glamorous but neither is trying to fix a website held together by 14 increasingly desperate !important declarations.
Why Must Development References Be Removed?
Internal AI references, prompts and development comments should not appear in production website output. They make the implementation look careless and can expose unnecessary information about the development process.
We discovered references to Claude Code inside published source code during our own work.
That did not necessarily harm the visible page but it showed that the final quality-control process was incomplete.
AI-generated code may contain tool names, temporary instructions, testing notes, placeholder URLs or comments written for the development session.
Those details need reviewing before deployment.
The code should be treated like work supplied by an external contributor. It requires inspection, cleanup and ownership.
It does not become trustworthy merely because the model sounded confident whilst producing it.
How Should You Test An AI-Built Website?
An AI-built website should be tested visually, functionally and technically. The coding agent’s own report is useful but it is not independent verification.
At a minimum, we need to check:
Desktop, tablet and mobile widths
- Navigation
- Forms
- Buttons and links
- Content editing
- Elementor compatibility
- Browser behaviour
- Keyboard navigation
- Colour contrast
- Loading performance
- Analytics and conversion tracking
- Structured data
- Canonical tags
- Indexing directives
- Source code cleanliness
Responsive testing needs several widths rather than one desktop screenshot and one phone.
Layouts often fail at the awkward points between common devices. Text may become too narrow before columns stack or decorative elements may overlap at a particular laptop width.
Forms deserve particular attention.
A successful submission is not enough if the lead never reaches the business or the conversion event fails to fire.
Testing should follow the complete journey. The website exists to do a job rather than pass a screenshot competition.
How Should AI-Built Websites Work For Search?
An AI-built website must meet the same search requirements as any other website. It needs crawlable content, clear architecture, useful information, sound technical foundations and credible evidence.
Google’s guidance states that its generative search features still rely on core search ranking and quality systems. There is no need for a separate collection of magical ‘AI SEO’ tricks. Google’s official guide to generative AI search emphasises valuable non-commodity content and established SEO practice.
The method used to build the page does not create search value by itself.
A beautiful AI-generated interface can still obscure content inside scripts, weaken heading structure or remove important internal links.
The brief must therefore include search requirements from the beginning.
SEO should not be sprinkled over the finished page like parsley.
What Makes A Website Accessible To Search Engines And LLMs?
Search engines and LLM-powered retrieval systems need accessible, understandable and attributable content. Important information should normally appear in clean HTML with sensible links and descriptive headings.
AI crawlability is not one universal setting.
Different systems use different crawlers for search, retrieval or model-related purposes. Website owners need to understand what they are controlling before blocking anything.
Content also needs to be explicit.
If the company name, services, location and expertise are hidden beneath vague language then machines may struggle for the same reason visitors do.
Clarity is not the enemy of creativity.
A distinctive website can still state plainly what the company does, who it helps and why its experience matters.
How Do Structured Data And Entity Salience Help?
Structured data helps search engines understand entities and eligible content types. Entity salience describes how clearly a page communicates the people, organisations, places and concepts central to its meaning.
For GrowTraffic, relevant entities include GrowTraffic, Simon Dalley, SEO, PPC, content marketing, Bacup and Lancashire.
Those associations should be supported by consistent content, internal links and accurate organisation information.
Schema.org markup can reinforce genuine relationships. Google explains that structured data can help it understand page content and the entities described. Google’s structured data guidance covers the supported approach.
Structured data does not rescue weak content.
There is also no special schema type that guarantees inclusion in AI answers. Google’s current guidance specifically warns against over-focusing on AI-specific markup.
Use structured data because it accurately describes what exists. Do not use it as digital fancy dress.
What Does Google-Extended Control?
Google-Extended is a publisher control related to certain uses of website content by Google’s Gemini models. It is separate from the ordinary Googlebot controls used for Google Search.
That distinction matters because ‘blocking AI’ can refer to several different things.
Training, grounding, retrieval and search indexing are not automatically controlled by one instruction.
Website owners should record which crawlers they allow then revisit those choices as products and policies change.
A publisher protecting proprietary material may make a different decision from a service business seeking greater visibility.
Indiscriminate blocking is not a strategy.
The right decision depends on what you are protecting, how customers discover you and where you want the organisation’s information to appear.
How Should You Write Content For People And Machines?
Content for people and machines should provide clear answers supported by experience, evidence and useful detail. It should be easy to summarise without sounding as though it was written for a database.
We increasingly begin sections with a direct answer.
That gives a reader the conclusion quickly. It also creates a self-contained passage that search engines or LLMs can understand.
The rest of the section adds context, examples and qualification.
This does not mean writing hundreds of robotic question-and-answer blocks.
People still need personality, progression and a reason to continue reading.
The strongest content works at several depths. A visitor can scan the summary then continue into the explanation if the subject matters to them.
First-hand experience is increasingly important because generic information is cheap.
Google’s guidance on AI-generated content focuses on usefulness rather than banning AI involvement. It warns that producing pages at scale without adding value may breach its spam policies. Google’s guidance on generative AI content makes that distinction clear.
E-E-A-T still matters.
Experience, expertise, authoritativeness and trust cannot be manufactured by repeatedly claiming to be an expert.
This article has value because it is based on what I have actually been doing, what went wrong and what I learned.
AI has helped structure and express the experience. It did not live it.
Why Is Human Judgement Still The Scarce Resource?
AI has made production faster and more abundant. The scarce resource is now the ability to decide what should be created, what should be rejected and when the work is good enough.
ChatGPT can produce more briefs than we can implement.
Claude Code and Grok Build can generate more versions than we can responsibly test.
That moves the bottleneck from production to judgement.
I have to decide whether a recommendation reflects commercial reality, whether a design fits GrowTraffic and whether a technical dependency is justified.
I also have to recognise when several models are simply repeating the same fashionable assumption.
This is why the final decision cannot be outsourced.
The models do not understand the consequences in the same way the business does. They do not have to maintain the website, support the team or explain the cost to a client.
AI gives me greater capability.
It also gives me more opportunities to make the wrong choice.
How Do You Know When The Website Is Finished?
An AI-built page is finished when it meets agreed commercial, visual, editorial and technical standards. It is not finished merely because the latest prompt has been completed.
Generative systems have no natural stopping point.
Ask for another review and they will normally find another set of improvements. Some will be useful. Others will move the furniture around.
We need a definition of done.
The page should have a clear purpose, accurate content, coherent hierarchy and an obvious next action.
It should work across devices. Forms, tracking and links should function. The team should be able to edit it.
The code should be cleaned. Technical SEO and structured data should be checked.
At some point, further work becomes subjective polishing rather than meaningful improvement.
That is the time to publish, gather evidence and move to the next priority.
A website is supposed to support a business. It should not become an expensive digital model railway that is never quite complete.
What Have I Learned From Building Websites With AI?
I have learned that AI website development is not mainly about replacing a developer. It is about changing the relationship between ideas, expertise and implementation.
AI has allowed me to build things I could not personally code.
It is sometimes slower than making a simple change myself. However, it can be more consistent and much more capable across a wider system.
I have also learned that different models deserve different roles.
ChatGPT understands the backstory and helps me think. Claude Code handles advanced implementation. Grok Build currently offers a fresher creative instinct. Grok challenges. Gemini checks. DeepSeek occasionally provides another lens.
The process works because I inspect the result.
I send live pages, screenshots and source code back into the conversation. We work out what is genuinely wrong then create a more focused brief.
The Elementor lesson may be one of the most commercially important.
The best-looking solution is not necessarily the best solution if nobody else can edit it.
AI should integrate with the way the team works. It should not create a new dependency every time it creates a new component.
Most importantly, the website work has forced me to formalise decisions about GrowTraffic itself.
To build better service pages, I have had to become clearer about our positioning, pricing, process, commercial value and the clients we want.
AI has not simply helped us rebuild a website.
It has exposed parts of the business we had not explained clearly enough.
Conclusion
AI can help you build websites that are more ambitious, more consistent and more distinctive. It can also generate dated design, fragile code and endless revisions.
The difference is not the tool alone. It is the quality of the thinking, briefing, testing and judgement surrounding it.
If you are considering using AI to rebuild your website but need the work to support search visibility and commercial growth, speak to GrowTraffic. We can help you turn AI production into a website people can find, understand and actually use.
Frequently Asked Questions
Can AI Build A Professional Elementor Website?
Yes. AI can help design and develop professional pages that work with WordPress and Elementor.
You must explicitly require Elementor compatibility. Otherwise, the AI may hard-code important content inside templates or custom components that the wider team cannot safely edit.
Is Grok Build Better Than Claude Code For Website Design?
In my experience, Grok Build can produce more adventurous visual interpretations from looser instructions. Claude Code remains more advanced for complex implementation, codebase analysis and controlled technical work.
The better tool depends on the stage of the project. Grok Build may be useful for exploring a creative direction whilst Claude Code may be stronger for integrating and maintaining the chosen solution.
Should I Let An AI Coding Agent Deploy Directly To My Website?
Not without controls. Use backups, staging environments, defined permissions and a review gate before material changes reach the live website.
Small reversible changes carry less risk than structural edits. The agent should never receive broader access than the task actually requires.
How Do I Stop AI From Making Unrequested Website Changes?
State exactly which files, sections and behaviours may be changed. List approved content and components that must remain untouched.
Ask the agent to report anything outside scope rather than correcting it automatically. Review the resulting file changes as well as the visual page.
Will Google Penalise A Website Because AI Helped Build It?
Google does not judge a website simply because AI was involved in its creation. It assesses whether the resulting content and experience meet its quality and spam requirements.
Problems arise when AI is used to produce low-value content at scale, misleading information or technically poor pages. The publisher remains responsible for the final result.