Why is my Next.js app not showing on Google?

Diagnose indexing with HTTP checks, robots rules, canonical URLs, sitemaps, and Google Search Console.

By Antoine RossPublished Facts verified

Start with one public URL that should appear in search. Check that it works without signing in, that Google can crawl and index it, and what Search Console reports for that exact URL. A successful deployment, sitemap submission or indexing request does not guarantee that Google will index the page or show it for a particular search.

Google separates discovery, crawling, indexing and serving results. A page can be indexed but not rank for the query you tried. Its Search overview explains the stages.

Before you start

You need a deployed public Next.js site, permission to inspect its source and deployment configuration, and access to a verified Search Console property for its domain or URL prefix. Pick the actual intended canonical page, for example https://example.com/features, and replace that example with your own URL in the commands below. This guide targets public marketing or documentation pages; a private dashboard should remain protected even if it is absent from search.

1. Check the actual response

Open the page in a private browser window without signing in. It should show useful content, not a login screen, deployment protection, error page, or empty application shell. In a terminal inspect the public response and redirects:

curl -sS -L -D - -o /dev/null https://example.com/features

Read the status and Location headers in each response. A redirect should end at the intended public URL and a successful page should return 200. A 404, 5xx, authentication redirect or temporary deployment URL needs investigation in your route, host or access settings. Do not use a fake Googlebot user agent as proof of what Google received. Google's technical requirements describe public access, successful responses and indexable content.

Inspect the final page's rendered HTML and visible text in the browser. The meaningful description of the product should be present and understandable. Google can render JavaScript, but rendering is a separate stage; use the live inspection tool in the next step to see what Google can access. Do not put private content in a public response merely to make it searchable.

2. Inspect the URL in Search Console

In the verified property, paste the exact final URL into URL Inspection. Read the indexed result and its reason, then run Test live URL. The indexed report describes Google's last known version; the live test checks the current page and does not itself update the index. Compare the reported crawl permission, fetch result, indexability and Google-selected canonical with the page you intended.

If the live test cannot fetch the page, fix the specific server, firewall, redirect or access problem first. If it is accessible but not indexed, read the reported reason before changing code. If it is indexed, investigate the search query and page relevance instead of repeatedly requesting indexing. The site: operator can help exploration but is not a complete index inventory; use Search Console for the URL's reported state.

3. Check robots and noindex separately

Visit https://example.com/robots.txt and look for rules that match the page and Googlebot. In an App Router project, inspect the existing app/robots.ts or app/robots.txt owner as well as any host-level rules. Next.js documents its robots file convention. Remove an accidental crawl block for the intended public page, while preserving intentional exclusions for other routes.

Next, inspect the response HTML and headers for a noindex robots directive. This command can reveal a header; inspect the page source for a robots meta tag too:

curl -sS -L -D - -o /dev/null https://example.com/features

Check route metadata, parent layouts and any proxy or hosting headers before changing them. Google needs to crawl a page to see its noindex instruction; blocking it in can prevent that observation. A blocked URL can still sometimes appear in results. See Google's robots meta tag reference and technical requirements.

is a crawler instruction, not authentication. Protect account pages and APIs with server-side authorization, even if they are excluded from crawling.

4. Resolve canonical and sitemap signals

In the final HTML, find the canonical link and confirm it identifies the URL you want indexed, including the correct scheme, domain and path. Compare it with redirects, internal links and the sitemap. If www redirects to the non-www host, for example, the sitemap and internal links should point consistently to the final host. Search Console shows both the user-declared and Google-selected canonical where available. Google treats a canonical as a signal and can choose a different URL.

Open your actual sitemap.xml and check that it returns successfully and contains the intended public canonical URL. Exclude private dashboards, sign-in pages and temporary preview URLs. If the project uses app/sitemap.ts, inspect that source; Next.js describes the sitemap convention. Add a normal link to the page from a relevant public page so visitors and crawlers can discover it. Submit the sitemap URL in Search Console if appropriate and check its report for errors. A sitemap helps discovery; it does not guarantee indexing.

5. Deploy the fix and recheck

After fixing the specific source or configuration issue, deploy through your normal process. Repeat the public HTTP check and Search Console live test for the same final URL. Once the live test succeeds, request indexing in URL Inspection when appropriate. Record the date and reported status, then revisit the indexed report later. Google does not promise a particular crawl or indexing time, and submitting the same request repeatedly does not make indexing certain. See Google's crawling and indexing FAQ.

If the page is indexed but missing for a search, check that the page directly answers the intended reader's question, that its title accurately describes its content, and that people can reach it through useful internal links. Search results vary by query and context. There is no code change that guarantees a ranking.