Add SEO Basics to an AI-Generated Website
Check the built page, not only the AI prompt or source template. Give each public page an accurate title, a useful description, one preferred URL, and links that a browser and crawler can follow. Put the intended canonical URLs in a valid sitemap. Remove preview-domain references and accidental noindex rules before launch. These steps help search engines understand a site; they do not guarantee indexing, traffic, or ranking. Google's SEO starter guide makes that limit clear.
This is a first-launch checklist for generated static code. If an existing Wix, Squarespace, Webflow, WordPress.com, or Shopify site has disappeared from search, use the builder indexing diagnosis. If you changed old URLs, use the redirect guide. A title tag will not repair a broken redirect.
Which pages should appear in the sheet?
Start with every public page that has its own purpose: homepage, service page, contact page, article, or case study. Do not treat a site-wide head template as proof of unique metadata. AI generators often repeat the homepage title on every page or leave a preview URL in the canonical tag.
Here is an illustrative three-page QA sheet for a fictional repair business. It is an example to adapt, not a tested site.
| URL path | Page job | Title and description check | Canonical | Internal path | Decision |
|---|---|---|---|---|---|
/ | Explain the business | Names the service and area; description matches visible copy | Final HTTPS home URL | Links to service and contact | Inspect built HTML |
/repair/ | Explain one service | Different title and useful summary, not copied from home | Final HTTPS repair URL | Linked from home | Inspect built HTML |
/contact/ | Give a contact route | Names the contact task; no claim that a mock form sends | Final HTTPS contact URL | Linked from navigation | Inspect form behavior |
Use the actual final hostname once the domain is ready. Do not put localhost, a deployment preview, or an old domain in canonical tags or sitemap entries. Open each production URL directly and inspect the delivered <head> and rendered page. For JavaScript-heavy sites, check both the initial response and rendered result. Google's JavaScript SEO guide advises care with script-injected titles, descriptions, and canonicals.
What should I check in the HTML?
Write one concise <title> that identifies each page. Write a meta description that accurately summarizes that page, but expect Google to choose a different snippet when it better fits a query. Use a clear main heading and real text for important content. Link between pages with normal anchor links and descriptive labels. Check that the link target returns the intended page rather than a generic single-page-app fallback.
Choose one preferred HTTPS URL per page. Redirect duplicate hostnames or paths where the host allows it. Use a rel="canonical" link when duplicate URLs remain. Keep the canonical target consistent with navigation and sitemap entries. A canonical is a strong signal, not a command: Google explains that it may select another URL. Do not point every page at the homepage. That tells search engines the distinct pages are duplicates.
Look for noindex in meta tags and X-Robots-Tag response headers. Check robots.txt for a site-wide disallow left from staging. Do not block a page in robots.txt to make its noindex work; Google notes that a blocked crawler cannot read the page's meta rules. Keep private or draft content behind suitable access controls instead of relying on a crawl hint.
What belongs in the sitemap?
List the final, preferred, public URLs that return useful pages. Exclude drafts, preview URLs, redirects, and error pages. Generate or update the sitemap when routes change. Open the deployed XML file, parse it, and visit several listed URLs. The sitemap and canonical should agree. Google's sitemap guide calls submission a hint, not a guarantee of crawling or indexing.
Add structured data only for a type that fits the visible page and the current Google Search gallery. Validate it, but do not invent ratings, reviews, prices, or business facts. Do not add FAQ markup in pursuit of a guaranteed rich result. Google's FAQ change notice limits FAQ rich results to well-known government and health sites, and its structured-data policy guarantees no display even for valid markup.
How do I close the review after deployment?
Recheck the sheet on the final domain. Save the date, URL, observed title, canonical, robots result, sitemap membership, and pass or fix decision for each page. Then use Search Console's URL Inspection on representative URLs to see what Google can access; allow time for crawling. A live test can reveal a block, but an accessible page may still not be indexed. Recheck the sheet after the first major content or route change.
For the full cross-page release decision, use the launch checklist. For help writing a specific change request, prepare a prompt. Figment's AI editor access page describes the current early-access boundary; a prompt does not edit or publish the live site.
Sources and access date
The linked Google SEO starter guide, canonical guidance, sitemap guidance, and structured-data policy were accessed 2026-09-23.
