The two prompts to use before launching from Replit
Replit’s documentation describes a Plan toggle in the Agent chat. In Plan mode Agent reads your project and gives guidance without changing your files, while Build mode, the default, writes code. Use the first prompt in Plan mode, then switch for the second.
Step 1: diagnose in Plan mode
Review this Replit website for SEO launch readiness. Do not change any code.
The website's purpose: [describe the business and what visitors should do].
The pages that should be public: [list the routes, or say "the homepage and every page in the main navigation"].
The planned live address: [https://www.example.com].
Please answer each question from the project's code and configuration, and say "cannot tell from the code" where that is the honest answer:
1. List every public route you can find. Flag missing pages, duplicate paths and routes that depend on a login.
2. How is the app served: as a server-rendered app, as pre-built static files, or as a browser-rendered app? Name the file that shows it.
3. For each important page, would the main heading, body copy and internal links be present before browser JavaScript runs?
4. Are the title, meta description, canonical URL and robots setting correct and unique for every public page?
5. Is any noindex rule present in a meta tag, response header or robots.txt? Show where.
6. What does robots.txt contain, and does it block anything needed to render pages?
7. Is there a sitemap, which URLs does it list, and do they use the planned live domain?
8. Do internal links use the final routes, and do images have useful alternative text where needed?
9. Is there a proper not-found page, and could any public route return an error after deployment?
10. Find references to preview, development or temporary Replit addresses that should not appear after launch.
Return a table with: page or route | check | pass, warning or cannot verify | evidence | file. Then give me a numbered launch-fix plan in priority order. Separate confirmed code findings from items that need testing after publication. Wait for my approval before changing anything.Step 2: fix only what you approved
Implement only items [1, 3 and 4] from your approved plan. Make the smallest change that fixes each one.
Rules:
- Do not alter layout, styling, wording or any page that is not named in those items.
- Do not add new dependencies unless an item cannot be fixed without one. If it cannot, stop and explain first.
- Keep every public page's content in the HTML that the server sends, not only in client-side JavaScript.
- After each change, tell me which file you edited, what changed and how I can check it on the live site.
- If a change might affect existing URLs or redirects, stop and ask me before making it.
Finish by listing anything you chose not to change and why.Fill in the bracketed parts. In step 2, replace the numbers with the items from the plan that you actually approve.
When to use it
Use this pair when the main pages and wording are in place, but before you connect the final domain or announce the website. It gives you a launch checklist based on the project Replit can actually inspect.
Run it again after a major change to routes, templates or deployment settings. If the site is already live and you are investigating a specific Search Console warning, replace the website-purpose line with the exact problem and affected URLs.
Do not ask Agent to improve all SEO in one step. Review the plan first, approve a small set of changes and check the result. Replit can alter several connected files, so tightly scoped changes are easier to understand and undo.
What it checks
The review works through the foundations a Replit website needs before launch:
- Public routes and crawlable content, including what is available before browser JavaScript runs.
- Titles, descriptions, canonicals and robots settings for each important page.
- Robots.txt and sitemap setup using the final domain.
- Internal links, images and missing pages.
- Preview or development references that should not survive launch.
- Deployment checks that can only be confirmed on the published website.
The review separates what Replit can confirm in the project from checks that still need the deployed website or Search Console. This gives you a practical test list without presenting assumptions as facts.
The first one cannot change code, because Plan mode is read-only. The second one names exactly which approved items to implement and forbids side effects.
What Replit may still get wrong
- Agent cannot see Google’s view. It can read your code, but it cannot tell you the index status, selected canonical or last crawl date. Those come from Google Search Console.
- Deployment settings may sit outside the code. Headers, redirects and domain behaviour can depend on how the app is deployed, which is why the prompt allows “cannot tell from the code”.
- Plausible but wrong diagnoses. A confident explanation is still a hypothesis. Test it before accepting it.
- Wide edits. A fix for one page can alter shared layout files. Check the list of edited files against what you approved.
- No ranking promise. Correct technical foundations make pages eligible, not successful.
Replit creates checkpoints as Agent works, and its documentation explains how to roll back to a previous state. Check that a checkpoint exists before approving a build, and consult Replit’s checkpoint guide if you need to undo a change.
A worked example
This is an illustrative scenario, not a client result. Imagine a small booking site for a local dog groomer that is almost ready to move from its Replit development address to a custom domain.
You fill in the review prompt and run it in Plan mode. Agent might find a noindex tag left in the shared layout, a sitemap containing the temporary Replit address and the same title on every service page. It can show the relevant files, but it should mark redirect behaviour and the final live response as checks for after publication.
You approve those three code changes, switch to Build mode and paste the fix prompt with the item numbers filled in. After publishing, you view the source of the live homepage, test the sitemap and inspect the key URLs in Search Console. Whether and when Google chooses to index them is outside anyone’s control.
Next step: confirm on the live site
The most useful evidence comes from the published site and from Search Console, not from Agent’s opinion. Our Replit SEO service covers diagnosis and implementation for Replit-built sites.
Book a site review and we will check the live pages for you, or send us a message if you would like to describe the problem first. You can also browse the rest of the resources hub.