Vibe Coding SEO: Technical Problems and How to Fix Them
Before asking AI to rebuild your website for SEO, check what the published page actually returns. A finished browser preview can hide a generic title, a missing page body or an incorrect response status. Start with one page, identify the exact mismatch and verify the change on the public URL.
This guide shows the difference visually: what a visitor sees, what is in the HTML, what to change and what the corrected output looks like. It includes a controlled app demo and a heading issue from our own WordPress implementation.
Show me the before and after →
What does “vibe-coded website” actually mean?
A vibe-coded website is built or changed by giving an AI tool instructions in ordinary language. For example: “Build a pricing page with three plans,” then “Add a contact form and make it work on mobile.” The tool writes code, you review the result and you ask for changes.
The phrase describes how you build. It does not tell you how the finished site sends pages to a browser or search engine. That is why two AI-built sites can look similar but return very different HTML.
WordPress vs Lovable: what changes for SEO?
Two delivery methods to know: with server rendering, the page text arrives in the HTML response. With client rendering, JavaScript builds the page in the visitor’s browser. Pre-rendering prepares an HTML version in advance or when a crawler requests it.
| Setup | In plain language | Where to look first |
|---|---|---|
| WordPress | A publishing system. Themes, plugins and page builders assemble your pages. You can also use AI to write custom code for it. | Page settings, theme output, SEO fields, plugins and caches. AI-assisted WordPress work is one example, not the definition of vibe coding. |
| Lovable | An AI app builder. Your instructions become an application that you publish. | The deployed project’s rendering, public routes and metadata. Check its current stack and hosting rather than assuming all Lovable apps work the same way. |
| A custom app built with an AI coding assistant | The assistant edits a project. Its framework and deployment determine how pages are delivered. | Route files, rendering configuration, hosting rules and per-page metadata. |
Current Lovable detail: its documentation says newer apps use TanStack Start with server-side rendering. Older React + Vite apps receive pre-rendering for verified crawlers. An ordinary curl request can therefore differ from a verified crawler’s response. Check the published URL in Search Console before diagnosing a rendering failure. Sources: Lovable’s SEO documentation and WordPress features.
Example 1: the page looks finished, but the first response is empty
The visible symptom: a visitor sees a pricing page after JavaScript runs, but the first HTML response contains an empty container and the generic title “Example App.” Another route returns the same title.
Controlled demo: we ran the requests below against a small local test app. It reproduces an app-shell deployment problem. It is not an audit of a live Lovable project.
Before
Monthly and annual plans for your team.
Starter · Team · BusinessThe browser looks complete.
After
Monthly and annual plans for your team.
Starter · Team · BusinessThe same content is also in the response.
What the code is doing
The empty root container tells the browser where JavaScript will build the page. It is not the pricing content itself.
Before
<title>Example App</title>
<div id="root"></div>
<script src="/assets/app.js"></script>After
<title>Pricing | Example App</title>
<meta name="description"
content="Monthly and annual plans for your team.">
<main>
<h1>Choose a plan</h1>
<p>Monthly and annual plans for your team.</p>
</main>Why this matters: the first response does not describe the pricing page well. Google can render JavaScript, so this alone does not establish an indexing failure. Compare the initial response with the rendered page and Search Console’s live inspection. Google explains crawling and rendering separately.
What to change: identify how your public pages are delivered. If they should send full HTML, repair the existing server-rendering or pre-rendering setup first. Consider a different rendering approach only after you have established what is missing. A platform change is a larger job than correcting a route or publishing setting.
How the metadata difference can look in a search preview
Before
No page-specific description supplied.
After
Monthly and annual plans for your team.
What our test actually returned
| Route | Before | After |
|---|---|---|
/pricing/ | 200 · Example App No document H1 | 200 · Pricing | Example App H1: Choose a plan |
/about/ | 200 · Example App No document H1 | 200 · About | Example App H1: Meet Example App |
/this-page-does-not-exist/ | 200 · Example App No document H1 | 404 · Page not found | Example App H1: Page not found |
The checks above inspect HTML elements outside scripts. Finding the string <h1> inside a JavaScript bundle does not mean the response contains an actual heading element.
Example 2: “Page not found” still returns success
The visible symptom: you enter an invented URL and see “Page not found.” That looks sensible, but the server may still report HTTP 200, which means success.
Before
The screen and response disagree.
After
The screen and response now agree.
What the code is doing: a catch-all hosting rule can send every request to the application shell. A message drawn by the browser does not change the status already sent by the server. That mismatch can lead to a soft 404.
What to change: use the application or host’s supported not-found handling for unknown public routes. Check valid deep links and refreshes too, so fixing an invented URL does not break real pages.
# Run against your own public domain.
# Read the response status and HTML for two real routes.
curl -sS -i https://example.com/pricing/
curl -sS -i https://example.com/about/
# Read the status for a route that does not exist.
curl -sS -o /dev/null -w "%{http_code}\n" \
https://example.com/this-page-does-not-exist/No terminal? Open your browser’s developer tools, select Network, reload the page and select the main document request. Read its status and Response tab. Use Search Console’s URL Inspection for Google’s view. A source response is one part of the diagnosis, not a replacement for the rendered-page check.
Example 3: our theme printed a title above the designed heading
Real implementation: on our SEO service page, the saved WordPress page title was “SEO.” The custom layout already supplied the hero H1, “Be the result they actually click.” The theme title appeared above the designed heading.
Before
they actually click.
Two competing visible page titles.
After
they actually click.
The designed heading owns the page.
Before
Saved page title: SEO
Custom layout H1:
Be the result they actually click.
Theme also prints its page title.After
Page template: elementor_header_footer
Keep the custom hero H1.
Do not print the extra theme title.
Recheck wrapper-dependent styles.What changed: we used the elementor_header_footer template so the custom layout controlled its heading while retaining the site header and footer. We also checked styles that depended on the old page wrapper.
What we verified: the normal public URL returned one H1 with the intended text. The practical issue was heading ownership and layout. Multiple H1s are not an automatic Google penalty.
This WordPress example shows an AI-assisted implementation problem. The app examples above show a different layer: how routes and content are delivered. The fix belongs to the layer that caused the observed problem.
What else should you check before launch?
- Indexability and canonicals: check for an accidental
noindex, a robots.txt block or a canonical pointing at staging. Keep intentionally private pages protected. Google’s noindex guidance. - Internal links: use real
<a href="…">links for navigation. A click handler alone does not provide the same discovery path. Connect relevant published pages using your semantic content architecture. Google’s crawlable-link guidance. - Structured data: keep organization and author identities consistent with the visible page. Check the JSON-LD syntax and the requirements for any Google search feature you target. Google’s structured-data introduction.
- Performance: measure the deployed page before removing scripts. Use field data where available and lab tools to investigate slow loading, layout shifts and delayed interactions. Google’s Core Web Vitals guidance.
One release lesson from our work: a special cache-busting request showed corrected markup while the normal URL still served the older version. Verify the ordinary anonymous URL after clearing the relevant cache. Save that response, not just the editor preview.
Put the guide to work
Start here: investigate one real URL
Choose one important public page, capture the failure and fix its cause before rolling the change across the site. Use the same evidence whether you work with an AI coding assistant, a developer or both. Your first deliverable is a reproducible issue, not a longer list of SEO warnings.
- Open Google Search Console and select your property. In the Page indexing report, open a relevant exclusion reason and choose an example URL that you actually want indexed. A deliberately private page or an expected duplicate is not a defect. For a newly launched site with no report data, start with a priority URL from your public route list.
- Inspect the exact URL. Record the indexed status, last crawl and any reported blocking reason. Compare the user-declared and Google-selected canonical in the indexed result. Then choose Test live URL to check the current deployment. The live test cannot tell you which canonical Google will select.
- Collect evidence before changing code. Save the response status and headers, title, description, robots directives and canonical from the public page. Compare initial HTML with rendered content. In the live inspection, use the tested-page view to examine HTML, a screenshot and resource information where available.
- Name the smallest testable failure. Write “the description contains JavaScript from the page-builder field,” rather than “SEO is broken.” If the evidence does not establish a cause, keep it as an investigation. A “Crawled, currently not indexed” status alone does not prove that JavaScript is the problem.
Search Console distinguishes indexed information from a current live test. See Google’s URL Inspection instructions.
How to fix technical SEO problems with AI
Give an AI coding assistant the evidence and the relevant project files, then ask for a small, reviewable patch. A chat tool without repository or browsing access cannot verify your implementation. Paste the necessary excerpts or give your approved coding tool access to the project. Remove credentials and private data from anything you share.
Use the heading example above to see what a focused AI task looks like. Use a branch, staging environment or restorable backup for your change.
The filled prompt below uses the resolved H1 example above. Orange text marks the actual page URL, heading and platform details to adapt.
Investigate heading ownership on this page:
URL: https://pinnaclerank.com/services/seo/
Platform: WordPress with a custom page layout.
Known implementation details:
- Saved page title: SEO
- Intended custom hero H1: Be the result they actually click.
- An unwanted theme page title appeared above the custom hero.
- The implemented template was elementor_header_footer.
- Our subsequent public check found one intended H1.
Treat this as a diagnosis and verification task, not an instruction to change a page that is already correct. Inspect the current DOM and identify the owner of each visible title. Report the H1 count and actual heading text. If you cannot inspect the page or project, ask for the HTML and relevant template files.
If the unwanted title is reproducible on my page, show the smallest source-level fix. Explain whether the issue belongs to a theme template, page setting or custom component. Do not hide the title with CSS or change all H1s to H2s. Do not apply the WordPress template name to another CMS or framework.
Preserve the custom hero, site header, footer and page layout. Show the proposed diff or setting change before deployment. Check wrapper-dependent styles on desktop and mobile.
Acceptance: one intended main H1 with the approved text; no extra theme title; correct layout and navigation at the normal anonymous URL after cache clearing. Report what was tested, what remains unknown and how to roll back.Review before deployment: check which file or CMS field changes, which other pages inherit it and how to undo it. Ask the assistant to run checks it can actually perform and return their output. A generated explanation is not evidence that the deployed page is fixed.
How to turn the finding into a developer ticket
Give your development team an observed failure, expected output and acceptance criteria. The filled ticket below uses the same resolved heading issue. For a new issue, let the developer identify the responsible component and estimate the change. If you also used AI, attach its proposed diff as a suggestion and distinguish it from verified findings.
Title: Remove the unwanted theme title above the custom SEO hero
Example URL: https://pinnaclerank.com/services/seo/
Context: WordPress custom page layout
Observed during implementation:
The theme page title appeared above the custom hero heading.
Saved page title: SEO
Intended hero H1: Be the result they actually click.
Source change used:
Page template set to elementor_header_footer.
Check styles that depend on the previous page wrapper.
Acceptance criteria:
- One main H1: Be the result they actually click.
- No unwanted theme title above the hero.
- Site header, footer, navigation and hero layout still work.
- Desktop and mobile checks pass after the template change.
- The normal anonymous URL serves the corrected output after cache clearing.
Evidence: attach before/after DOM excerpts and layout screenshots.
Regression: sample another page using the same template and an unaffected page.
Rollback: restore the saved template setting and any dependent style changes.
This example is already resolved. For your own ticket, replace the URL and approved heading, reproduce the defect and assign a developer, reviewer and release date.Agree ownership before implementation: the SEO or content owner defines the intended page behavior, the developer owns the source change and deployment, and a reviewer checks the public output. For a shared-template defect, include at least one other affected route and one route that should remain unchanged.
How to verify the fix and close the task
- Repeat the failing check after deployment. Clear the relevant CMS or CDN cache, open the normal URL without login cookies and save the corrected response. Test direct visits, internal links and the affected layout on desktop and mobile.
- Check for regressions. Sample other routes using the changed template. Confirm intended private pages remain protected and a nonexistent URL still returns 404. For a performance fix, repeat the relevant measurement rather than judging by appearance.
- Return to URL Inspection. Run a live test on the corrected public URL. Where appropriate, request indexing. Use the report’s Validate fix option when available for a resolved issue group. Record the request date; a successful test or request does not establish that the page is indexed.
- Separate delivery from search follow-up. Close the implementation task when its acceptance criteria pass. Keep a follow-up with an owner and review date to inspect subsequent crawl and indexing information, then monitor impressions and clicks. Do not report a ranking gain merely because the release passed QA.
Your completed task should contain: the affected URL, before-and-after evidence, the source change, test results, deployment date, rollback method and monitoring owner. Repeat that process for the next confirmed problem. For help diagnosing issues across several templates, a technical SEO review can turn the findings into a prioritized implementation backlog.
Does building with AI change the SEO requirements?
Check the usefulness of the page and the output you publish. For Google AI Overviews and AI Mode, Google specifies no special schema or additional technical optimization beyond the usual search requirements. Google’s AI search guidance.
The working rule: describe one observed problem, fix its source and repeat the same check afterward. Keep the implementation result separate from the later question of whether Google indexes or ranks the page.