
Check one specific setting first: a site-visibility toggle, a password page, or a noindex tag, all of which are more common causes than anything Google itself is doing. Every builder below has at least one built-in setting that hides a site or page from search engines, on purpose, and it's easy to leave one on from before launch. This post walks through the exact setting on each platform, then the two Google tools that tell you what's actually true instead of guessing from a site: search.
Open Settings → Crawlers. If Block Search engine crawlers is checked, Squarespace adds Disallow: / to your site's robots.txt, which blocks search engines from the whole site (Squarespace). That's a site-wide block. A single page can also be hidden individually: hover over the page, click the gear icon, go to the SEO tab, and check whether Hide page from search results is switched on — Squarespace notes that "Blog pages have more options" and that "Homepages and individual collection items don't have a Hide page from search results toggle" (same source). If you hid a whole blog or store section this way, every post or product under it is excluded too, since "adding the tag to a collection page also tells search engines to exclude its collection items from search results."
Wix separates these into two settings. For the whole site: go to SEO & GEO in your site's dashboard, scroll to Tools and settings, open SEO Settings, and check whether Let search engines index your site is off. For one page: in the editor, open Pages & Menu, click the More Actions icon next to the page, open SEO basics, and check the Let search engines index this page toggle (Wix). Two Wix details matter here: public member pages such as Followers and Profile stay indexable unless you switch them off one by one, and turning indexing off site-wide removes the per-page controls (same source).
Webflow's indexing settings live in two places, and it's easy to check the wrong one. If your site is only reachable at its .webflow.io subdomain (not a connected custom domain), check the Staging indexing setting: when it's off, search engines are told to ignore the .webflow.io staging address, which is what you want once a custom domain is live, and a problem if the staging address is your only address (Webflow). Separately, an individual page can carry its own noindex tag: open Page settings → SEO settings and check whether Sitemap indexing is toggled off. Webflow states this "adds <meta content="noindex" name="robots"> to your site page," and — importantly — that a page can still show up already-indexed even after you fix the toggle, "if a search engine finds your content either because it was published previously, or there's a link to that content from other content online." Webflow also notes that a noindex tag added through custom code does not remove the page from the auto-generated sitemap; the Sitemap indexing toggle does both.
Go to Settings → Reading, find Site Visibility, confirm the site is set to Public, and check whether Discourage search engines from indexing this site is ticked. WordPress.com's own support notes an easy-to-miss side effect: "not all search engines may respect this setting," and turning it on "will also exclude your blog posts from showing in the WordPress.com Reader" (WordPress.com) — so a site that vanished from both Google and the Reader at the same time usually has this one box checked. This setting is different from a private or coming-soon site, which blocks all visitors, not just search engines; confirm your site is actually public before assuming this checkbox is the cause.
Open the Online Store page in your Shopify admin and look at the access setting menu: if it shows a Private label, the store is in private mode (extra private-mode settings, such as the password, live under Online Store → Preferences). New stores start in private mode by default. Shopify is direct about what this does: "all of your online store's pages are hidden from visitors and search engines, and your online store displays a customizable landing page instead" (Shopify). This is the same password page many stores use before launch, and it's easy to forget switched on after going live — a store behind it is invisible to Googlebot the same way it's invisible to a customer without the password.
If none of the above is the cause, stop guessing from a site:yourdomain.com search — Google is explicit that "the site: operator doesn't necessarily return all the URLs that are indexed under the prefix specified in the query" (Google Search Central). Use the real tools instead:
A site can also simply be new. Google's crawling and rendering queue takes time by design, and a site with no sitemap and no external links may sit unindexed for longer than a well-linked one — that's a timing issue, not a setting to fix.
Flipping the toggle only removes the block going forward; it doesn't retroactively re-index anything. After you fix a noindex tag, a robots.txt block, or a private-mode setting, go back to Search Console's URL Inspection tool and use its request-indexing option on your most important pages, rather than waiting for Google to notice on its own schedule. Give it days, not hours — Google's own JavaScript-rendering documentation acknowledges that even ordinary crawl and render queues "can take longer than that" few-seconds baseline, so a fixed setting on a brand-new site can take longer to show results than the same fix on an established one. If a page shows a persistent error in URL Inspection after the underlying setting is fixed, that's a separate issue (a server error, a redirect loop, or a canonical pointing elsewhere) and worth inspecting on its own rather than re-checking the same visibility setting again.
If your site is a Lovable app rather than one of these builders, the causes and the fix order are different — Lovable's rendering setup changes what Google sees before any of the settings above come into play. See why a Lovable site isn't showing on Google for that case specifically. And if you're rebuilding the site anyway rather than debugging the old one, our export capability matrix and redirect guide cover what has to survive the move.
Bottom line: Check the specific visibility, password, or noindex setting for your platform first — it's the most common cause by far. Confirm the real state with Search Console's URL Inspection tool and a submitted sitemap, not a site: search. Then give a genuinely new or newly-fixed site time to be crawled before assuming something else is wrong.