If every page of your vibe-coded website shows the same search title or description, inspect the published routes and their shared template before rewriting anything. First decide whether the URLs are genuinely different pages. Then give each distinct public page a title and description that match its visible content, make the template select the right values for each route, and check the deployed result again. If the URLs show the same content, the better fix may be consolidation rather than a new title for every copy.
Google recommends descriptive, distinct titles and page-specific descriptions, but it may generate a different title link or snippet in search results. This guide shows how to diagnose the source of repetition, brief your AI coding tool precisely, and verify the live pages. It is a focused repair within the broader vibe coding SEO workflow.
Find which public routes share metadata
Begin with the live domain and a list of intended public pages. In Screpy's website audit, review the Duplicate Title and Duplicate Description findings. Those filters group URLs that the crawl saw with the same values. They do not, by themselves, tell you whether the pages should all be indexed or whether the repeated wording caused a traffic decline.
Record a small sample of the affected URLs. For each one, capture its status, canonical URL, HTML title, meta description, visible main heading and the first useful paragraph. Include a direct visit to the URL after a hard refresh. A builder preview or browser tab changed by in-site navigation may not represent the deployed response to a fresh request.
For example, this fictional site has three public routes but one inherited template title:
| URL | HTML title observed | Main page topic |
|---|---|---|
/ |
“Home | Example” |
/salon-reminders/ |
“Home | Example” |
/pricing/ |
“Home | Example” |
That pattern suggests a shared default, but do not jump to the fix yet. Check whether /salon-reminders/ and /pricing/ actually return distinct content and whether either URL redirects or declares the homepage as canonical. Also sample pages without a warning so you can tell whether the issue affects one template, a whole directory, or the entire site. If the crawl missed a public route, investigate its links and crawl access before declaring the metadata clean.
Decide whether the URLs should be separate pages
A duplicate-title report is a clue about URLs, not a command to invent different sentences. Classify the affected set before asking the AI tool to change a shared layout:
| Pattern | What to verify | Appropriate direction |
|---|---|---|
| Distinct public pages share one default title and description | Each URL has a different purpose and meaningful body content | Supply page-specific metadata and ensure the template selects it by route |
| Multiple URLs show essentially the same page | Preview domain, old path, slash variant or another duplicate URL | Choose the intended public URL; use consistent links, redirects or canonical signals as appropriate |
| Browser navigation changes the tab title, but a fresh direct load shows the default | Compare the direct response and rendered page for each route | Fix route-aware output or rendering, then retest direct visits and Google inspection |
The second pattern is especially important. If both example.com/salon-reminders/ and a temporary preview URL show the same page, creating two different titles would hide the URL problem rather than solve it. Google's canonical documentation describes how duplicate URLs can be consolidated and why Google may choose a canonical other than the one you declared. A canonical is for materially similar content; pointing genuinely distinct pricing and service pages to the homepage is not a sensible shortcut.
The third pattern does not mean JavaScript is inherently unusable for SEO. Google can process JavaScript. It means you need to inspect what the published route returns and what Google renders, not only what your current browser state displays. If an important route itself fails on direct access, use the pre-launch website audit to fix that blocker first.
Only the first pattern is a straightforward “write better titles and descriptions for these pages” job. This classification keeps the next edit small and prevents the AI assistant from producing hundreds of cosmetic variations across URLs that should not exist separately.
Give each distinct page a clear title and description
Write the page's job in one sentence before writing its tags. Who is this page for, what question does it answer, and what action can the visitor take? Then make the HTML title, description, visible heading and opening text agree. A title that promises pricing while the page hides every price behind a signup is not made useful by repeating the word “pricing.”
Here is a fictional route map. Its wording would need to be checked against the features and prices of a real website:
| Public URL | Page purpose | Title | Description |
|---|---|---|---|
/ |
Explain the overall service | `Appointment reminders for small businesses | Example` |
/salon-reminders/ |
Address salons specifically | `Appointment reminders for salons | Example` |
/pricing/ |
Support a buying decision | `Appointment reminder pricing | Example` |
/blog/reduce-no-shows/ |
Teach a process | `How to reduce salon no-shows | Example` |
Each description should be replaced if the real page does not deliver that promise. The blog guide, for instance, must actually explain methods and limitations; it cannot be a disguised sales page. The service page needs salon-specific detail, not a cloned homepage paragraph with “salon” inserted. This is why page content and metadata are one editorial decision.
Keep the most distinguishing words visible and avoid a repeated block of brand boilerplate. There is no Google rule that every title must contain a fixed number of characters or that every description must be exactly 160 characters. A concise, accurate sentence is more useful than a keyword-stuffed one. Google may show different text from your HTML because it builds title links and snippets from the page and query context. Your job is to provide a sound page-specific signal, then verify what the live site actually serves.
Fix the shared template without breaking other routes
Once you know which URLs deserve separate pages, change the source of the metadata. In many vibe-coded sites, the homepage title is hard-coded in a shared layout. Editing the visible heading on /pricing/ will not fix a <title> that every route inherits. Find the layout, route definition, or page-level metadata setting that builds the document head. Assign page-specific values at the route level; keep shared brand formatting in the common template.
Your builder may offer a page settings panel, a route metadata API, or a framework head component. Use the mechanism supported by your actual project. A general instruction to an AI coding assistant is:
For the four distinct public routes in the attached route map, set the exact approved HTML title and meta description for each route. Keep the shared layout, canonical rules and private routes unchanged. Show the changed files, then test the head tags on a direct request to each published URL. Do not invent new pages or descriptions.
Review the generated diff before deployment. A broad code edit can overwrite canonical links, add duplicate <title> elements, or place a second description tag in a component nested under the shared layout. Avoid a blanket “make every URL unique” rule: tracking parameters, filtered views, authentication screens and true duplicate URLs may need different treatment. Fix the public page set you classified in the previous step.
Check four acceptance conditions in the deployed site:
- A direct visit to every distinct public route shows its intended page and a single appropriate title and description.
- The values match the visible content rather than an imagined product feature.
- The homepage and other unrelated routes retain their existing, correct metadata.
- Duplicate URL variants still follow the chosen canonical or redirect behavior.
Google can process JavaScript-generated metadata, but a locally correct component does not prove what a crawler receives. Test the published URL and its rendered page. Platform defaults and rendering modes differ, so verify this behavior for your own build instead of assuming all AI-built websites work alike.
Recrawl and compare the live page with Google
After publishing the fix, recrawl the affected routes. Screpy's website audit can help you compare the title and description inventory across the crawled URLs. Recheck the routes that were flagged, and open each one yourself to confirm that the headline, body and metadata describe the same page. A clean duplicate-metadata report is useful evidence, but it does not mean every page is eligible for indexing or that a search result will show your chosen wording.
Next, inspect a few representative URLs in Google Search Console. Check the indexed URL and selected canonical, then use the live test when you need to see the page Google can currently fetch. If Google has not recrawled since your deployment, its indexed information may still describe the old version. You can request indexing for an eligible URL, but the request is not a promise of immediate recrawling, indexing or ranking.
Finally, search for the pages by their topic over time and compare the displayed result with your page. Google may generate a title link or snippet from on-page text or other signals; a different display is not, by itself, proof that the deployed tag failed. First confirm the actual HTML and the indexed canonical. Then improve any wording that misrepresents the page or hides its main purpose.
For a vibe-coded website, the lasting fix is a route map that says which public URLs have distinct intent and which ones should consolidate. Give those pages accurate metadata, verify the live output, and revisit the map whenever you add a new page. That workflow prevents the same shared-template error from returning with the next AI-generated route.