Google Search Console after a migration

1Connect Google Search Console inside the Lovable project

You, in the browser

• In the Lovable project, open the + menu next to the chat box → Project connectors → All connectors → Google Search Console → Connect.
• A Google sign-in window opens. Sign in with the Google account that already owns the Search Console property for the old site — not a personal account, and not a fresh one. If the site is on Google Workspace, that is usually the marketing or webmaster account.
• Approve the read access Google asks for. The connection lives in that Lovable project only; Sitejump never holds Google credentials and never sees the data.
• Do this while the old site is still live, so the ranking baseline can be read before the domain moves.

One step is yours and takes about a minute: in this project, open + → Project connectors → All connectors → Google Search Console → Connect, and sign in with the Google account that owns your current Search Console property. Do it while the old site is still live so I can read your ranking baseline before the switch.

2Make sure a verified property exists (or verify one)

Done for you in Lovable

• If the old site was already verified, the ownership meta tag was extracted from it and re-emitted in the rebuild, so the property stays verified through the move — nothing to do.
• If there is no property yet, verify one with the meta-tag method: request a verification token, write <meta name="google-site-verification" content="…"> into the project's root head, ask the user to publish once, then verify and add the property.
• Google cannot see a tag that only exists in preview. If verification fails with 'could not find the meta tag', the deployment is stale — publish again and retry, do not switch to DNS or file upload.
• Property type: a Domain property (DNS record) covers every subdomain and both http/https; a URL-prefix property covers exactly one scheme + host. A verified root URL-prefix property is enough for reports and sitemaps — pick it unless the user wants subdomain-wide coverage.
• Whichever is chosen, the site must resolve on one canonical host (https, and either www or non-www with the other redirecting), or reports split across two properties.

Your old site's Search Console verification tag is already re-applied in the rebuild, so ownership carries over. If Google can't find a property yet, I'll add the verification tag myself — you'll just need to publish once.

3Submit the sitemap after launch

Done for you in Lovable

• Once the domain points at the new site, submit https://yourdomain/sitemap.xml in the connected property.
• The sitemap is generated by the migration (get_agent_surfaces) and lists every rebuilt page, so nothing is left for Google to discover by luck.
• Re-submit only when the sitemap's contents change — repeated submissions do not speed up crawling.

New sitemap submitted — Google now has the full list of pages on the new site.

4Request indexing for the pages that matter (manual, in the browser)

You, in the browser

• Submitting a sitemap does not force a crawl. It tells Google the URLs exist; Google still decides when to fetch them.
• The one thing that reliably speeds up a fresh site is 'Request indexing' in Search Console's URL Inspection — and that is a manual browser action. No API, no integration and no agent can trigger it, including this one.
• Open Search Console → URL Inspection → paste the URL → Request indexing. Do the homepage first, then the 5–10 pages that actually earn money (top service, product, pricing and contact pages). There is a daily quota, so do not queue the whole site.
• Do this on launch day, after the domain resolves and the redirects are live — indexing a URL that still 404s wastes the request.

One thing I genuinely cannot do for you: 'Request indexing' in Search Console only works as a manual click in the browser. Open Search Console → URL Inspection, paste your homepage, hit Request indexing, then repeat for your top 5–10 pages. That's the fastest way to get a freshly launched site crawled.

5Set expectations: indexed is not the same as ranking

Done for you in Lovable

• A newly launched or newly verified site typically gets its first crawl within days, not hours. Search Console's performance report also lags by 1–3 days and omits very low-volume queries, so an empty report is not proof of zero traffic.
• Being indexed only means the page can appear. Ranking needs query history, links and time — brand-name searches usually work first, competitive terms take weeks to months.
• Fast check any time: search site:yourdomain.com in Google to see what is actually in the index.
• On a migrated site the redirects do the heavy lifting: the old URLs keep their authority as long as each one resolves to its new page in a single permanent hop. Run the free launch verification to prove that, and fix anything red before worrying about rankings.

Expect the first crawl within a few days, and remember indexed ≠ ranking: your brand name surfaces first, competitive terms build over weeks. Search site:yourdomain.com to see what's already in the index. Because every old URL 301s to its new page, the authority you had carries over — I can re-run the launch verification any time to prove it.

6Why the old WordPress site showed up faster (and what actually matters)

Done for you in Lovable

• It is almost never the stack. A WordPress page that appears in Google within hours is nearly always on a domain Google already crawls daily — years of history, links and a known crawl rhythm. A brand-new domain on any platform, WordPress included, gets a slow discovery schedule.
• There is one genuine technical difference, and it is not about WordPress: a page whose copy only appears after JavaScript runs is a blank page to most crawlers and to every AI answer engine. That is why the rebuild must be server-rendered — run run_indexability_check to prove each page's text, title, h1 and canonical are in the raw HTML.
• Discovery still beats submission: internal links from the homepage to every page, plus a few external links (company profiles, socials, partner and directory pages) get a new host crawled far faster than a sitemap alone.
• On a migration the redirects carry the authority. Keep the same domain, 301 every old URL in one hop, and the site inherits its history instead of starting from zero — which is why a migrated site indexes far faster than a genuinely new one.
• Do not change the domain and the platform in the same week if it can be avoided. If the domain must change, keep the old one live and redirecting for at least a year.

If your old WordPress site turned up in Google instantly, that was the domain's history, not WordPress. Two things actually decide it: the page must be readable without JavaScript — I've checked that on every page — and the domain needs links pointing at it. Because we kept your domain and 301'd every old URL, you inherit that history instead of starting over.

7Watch coverage and 404s for the first weeks

Done for you in Lovable

• With Search Console connected, check the Pages/coverage report weekly for the first 6–8 weeks: new 404s, 'crawled – currently not indexed', redirect errors and canonical surprises.
• Cross-check every new 404 against the redirect map and add a 301 for anything missing.
• Re-run the launch verification after any structural change — it is free and repeatable.

For the next few weeks I'll check coverage errors and new 404s against your redirect map — just ask me to run the check any time.

8Make the site quotable by AI answer engines (GEO)

Done for you in Lovable

• ChatGPT, Perplexity, Claude and Google's AI Overviews read the same page a crawler reads — so the AI findability files written during launch (llms.txt, robots.txt, sitemap.xml, index.json and a Markdown mirror of every page) let them read the site without executing JavaScript.
• What makes a page citable: one clear H1, factual answer-shaped paragraphs near the top, real headings instead of styled divs, descriptive alt text, and valid structured data (Organization, Product, Article, FAQ, Breadcrumb) — all carried over from the old site by the migration.
• Allow the AI crawlers in robots.txt if the site wants citations: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended. Blocking them is a valid choice, but it removes the site from those answers.
• Answer engines crawl on their own schedule and there is no 'request indexing' equivalent — citations follow being crawlable, factual and structured, not from any submission form.

Your AI findability files are in place: llms.txt, robots.txt, sitemap.xml and a Markdown mirror of every page, so ChatGPT, Perplexity, Claude and Google's AI Overviews can read the site without running JavaScript. There is no 'submit' button for those — they crawl on their own schedule, and clear headings plus your structured data are what get you quoted.

9Check analytics and the other Google integrations

Done for you in Lovable

• The GA4, Google Tag Manager, Google Ads and Meta Pixel IDs found on the old site are re-emitted in the rebuild, so measurement continues without a gap — confirm they fire on the live site with GA4 realtime.
• Anything else the user wants (Google Analytics, Sheets, Drive, Gmail, Calendar) connects the same way as Search Console: + → Project connectors, inside their own project, with their own account.
• There is no Google Forms integration — an embedded Google Form is rebuilt as a native form that can still write to the same Sheet, email via Gmail, or post to a CRM.

Your GA4/Tag Manager IDs from the old site are already re-applied — open GA4 realtime after launch to confirm data is flowing. Any other Google service (Analytics, Sheets, Drive) connects the same way as Search Console, in this project's connectors.

When something looks wrong

Search Console says my URL is unknown to Google

The property was verified recently and the page has not been crawled yet. Confirm the page returns 200, is in the sitemap and is not blocked by robots.txt, then request indexing manually in URL Inspection and wait a few days.

Verification keeps failing with 'could not find the meta tag'

The tag exists in the project but not on the live site. Publish, load the live URL, view source and confirm the exact tag is in the head, then verify again. A tag added only in preview, injected by client-side script, or placed on a non-root page will not count.

The property list is empty or shows the wrong site

You signed in with a Google account that does not own the property. Disconnect the connector, reconnect and pick the account that has access, or have the owner add you as a full user in Search Console first.

Data is split between www and non-www

Both hosts resolve. Pick one canonical host at the DNS/host layer and 301 the other to it, or use a Domain property that covers both.

Pages are indexed on the old CMS but not the new site

Check the redirects first: every old URL must reach its new page in one permanent hop. Run the launch verification and fix every red row — chains, temporary redirects and 404s all stall re-indexing.

Nothing at all is being indexed

Look for a leftover noindex from staging, a Disallow: / in robots.txt, or a canonical still pointing at the old domain. The migration writes correct files, but a later manual edit can undo them.

Why did my WordPress site index instantly and this one doesn't?

Domain history, not the platform. An established domain is crawled daily; a new host is discovered slowly whatever it runs on. The one real technical difference is JavaScript-only rendering — run the indexability check to confirm every page's text is in the raw HTML — and after that it comes down to links pointing at the domain.

The site is indexed but never appears in searches

Indexed is not ranked. Search your brand name and site:yourdomain.com first. A fresh domain has no query history; competitive terms take weeks to months of content and links regardless of how the site was built.

Can Lovable or Sitejump request indexing for me?

No. Request indexing exists only as a manual click in Search Console's URL Inspection — there is no API for it. Everything else (verification, sitemap submission, coverage reading) can be automated once the connector is in place.