A HubSpot page that isn’t indexed needs a diagnosis tied to its exact URL—not an automatic settings change. Check the indexing reason in Google Search Console, review the page’s noindex and robots settings, confirm which domain the URL uses, and look for the page in the sitemap. Treat rendered-content review as a separate check, then request a recrawl after you make a supported change.
Summary
- A “not indexed” status does not by itself mean the page has an error. Read the reason reported for the affected URL before deciding what to change.
- Check the affected page’s settings and path, confirm the URL uses the intended HubSpot domain, and look for that exact URL in the sitemap.
- After changing a page, use URL Inspection for a few URLs or submit a sitemap for many. Monitor progress; repeated requests for the same URL do not make Google crawl it faster.
Check the Google indexing status for the exact HubSpot page
Start with the affected URL’s reported indexing reason in Google Search Console. Google’s Page indexing report groups URLs by status and reason; a page listed as not indexed is not necessarily in error. The specific reason is the starting point for deciding whether to inspect a setting or take another action, according to Google’s Page indexing report .
Find the exact page in the report rather than treating the overall site count as a diagnosis. If the URL does not appear in the report, that alone does not tell you why; use URL Inspection for the individual page if you have access to the relevant Search Console property. URL Inspection is for properties you control.
The distinction matters: “not indexed” describes a status, while the reason gives context for what to check next. Google lists reasons that can be non-errors as well as reasons that may indicate a problem. A page reported as indexed can also have other issues, so the status does not replace reviewing any details shown for that URL.
Use the report to focus your next check. If the reason points to a page-level setting, inspect that page’s settings; if the page is absent from a sitemap or hard to discover through the site, check discovery paths. Don’t change a setting simply because the page is not indexed—first establish what the report says about that URL.
Why a New Webflow Page Isn’t Indexed—and What to Check→Check HubSpot page settings for a noindex directive
Check the affected HubSpot page for a noindex setting, then consider whether robots rules apply to its path. A page-level noindex setting and a robots.txt rule are separate things to review; the reported indexing reason can help determine which check is relevant.
A HubSpot Community discussion advises checking the page’s noindex setting and whether robots.txt blocks the relevant path. It’s community guidance, not proof that every HubSpot page uses the same settings workflow. One third-party article describes the page settings route as Settings → Advanced Options → Search Engine Optimization, with a “Don’t index this page” option. Treat that as a reported route, not a universal interface instruction.
The HubSpot knowledge article Prevent content from appearing in search results is relevant to the topic of keeping content out of search results, but the available page excerpt does not provide a step-by-step verification workflow. For the specific page, use its indexing report reason alongside the settings review rather than assuming that an account-wide or homepage setting applies to every page.
Check HubSpot domain identity before interpreting canonical URLs
Confirm which HubSpot-hosted URL you’re checking and whether it uses the domain intended for the site. A HubSpot Community reply says that using an hs-sites domain rather than a connected primary domain can create confusion about which URLs are canonical or primary. That is a reason to verify the URL’s domain identity before drawing conclusions from it.
Start with the exact URL shown in the indexing report. Compare its domain with the domain you expect visitors and search engines to use, and confirm that the affected page is being inspected under the appropriate site property. If the URL uses a HubSpot-hosted domain you did not expect, resolve which domain the page is meant to use before treating the report as evidence about another URL.
The community discussion provides this domain-identity caution, but it does not establish that a particular canonical target is wrong or should be changed. A domain check can clarify which URL you’re reviewing; it is not, by itself, a decision rule for editing canonical settings.
Once you’ve confirmed the domain, return to the exact URL’s indexing reason. If the report identifies a specific issue, use that reason to choose the next check. Don’t change a canonical setting based only on domain confusion; the domain check and the indexing diagnosis answer different questions.
Verify whether the HubSpot page appears in the sitemap
Look for the exact affected URL in the sitemap. Google describes a sitemap as an important way to help it discover URLs, particularly when a site has many URLs to submit. A sitemap is one discovery route, not a substitute for checking the page’s indexing reason or settings, according to Google’s recrawling guidance .
A HubSpot Community reply recommends submitting a sitemap and URLs to Google Search Console. Google’s guidance describes sitemap submission as a way to help Google discover many URLs; it also identifies internal links and other methods as ways pages may be found. If the exact URL is missing from the sitemap, check whether site links provide another discovery path instead of assuming the omission alone explains the indexing status.
A third-party HubSpot article reports that certain page settings can exclude pages from a HubSpot sitemap, including settings related to noindex, password protection, or sitemap inclusion. Use that information as a prompt to inspect the affected page, not as a diagnosis of why a particular URL is missing. The page’s own settings and reported indexing reason should guide what you check next.
Keep rendered-content review distinct from HubSpot index settings
A review of the published page’s rendered output is a separate check from reviewing HubSpot’s page settings or sitemap. It may be useful as an additional review of the page itself, but it does not replace the indexing report, a noindex check, a robots review, or a sitemap check.
Keep the questions separate. The Page indexing report tells you the reported status and reason for a URL; the settings review concerns whether a page-level directive or robots rule applies; the sitemap check concerns whether the URL appears in a discovery file. A rendered-content review is not itself a diagnosis of the reason shown in the report.
If you decide to add this review, treat it as a separate part of your investigation. Don’t infer from the mere fact that you reviewed the page’s output that you’ve confirmed the cause of non-indexing, and don’t substitute that review for the status and settings checks.
Return to the exact page’s reported reason after any additional review. Use the reason and the relevant page-specific checks to decide what action, if any, is warranted.
Decide whether a non-indexed HubSpot page needs a fix
A non-indexed page does not always need a fix. Google says non-indexed URLs are not necessarily excluded because of an error; read the specific reason before deciding whether the page’s status is intentional or calls for attention.
Some exclusions may be intended. The Page indexing report context identifies duplicates, noindex pages, and removed pages as examples where exclusion may be expected. If the page is meant to stay out of search results, its non-indexed status may match that purpose. If it is intended to appear, compare the reported reason with the page settings, relevant robots rules, domain identity, and sitemap entry.
Use the reason to prioritize your checks rather than treating every excluded URL alike. For a page-level noindex reason, review the affected page’s setting. For a discovery concern, check the sitemap and internal links. If the report identifies a different reason, follow the details shown for that reason instead of assuming one of these checks will apply.
The practical decision is whether the report describes an intended exclusion or a page-specific issue that conflicts with what you want for that URL. Make changes only when the page’s intended status and the evidence from its own checks support them.
Request Google to recrawl after making a supported page change
After you change a page, choose URL Inspection for a few URLs or submit a sitemap when you need Google to discover many URLs. Google documents both methods and says URL Inspection requests require owner or full-user access to the Search Console property. You can’t request indexing for URLs you don’t manage.
Crawling can take anywhere from a few days to a few weeks, according to Google’s recrawling guidance . That range describes possible crawl time, not a promise that the page will be indexed within that period. Monitor the URL’s progress rather than treating the request itself as proof of inclusion.
Repeatedly requesting a recrawl for the same URL won’t make Google crawl it faster. URL Inspection also has a quota for individual URL submissions, so use it for a small number of pages and use a sitemap when dealing with many URLs. Neither method replaces addressing a page-specific issue identified in the report.
After submitting, return to the status report or inspect the URL again to see what Google reports. Keep the distinction clear: a request is a way to ask Google to recrawl or discover a page; it is not confirmation that the page has been indexed.
Last content update: November 12, 2026.