How to Audit a Live Squarespace Site and Decide What to Fix First

This audit is for owners and teams working on a live Squarespace site that is indexed but not producing the organic search visibility they expected, or that has changed enough to justify a structured review. The trigger might be a traffic decline, key pages that do not appear for relevant searches, or a competitor that consistently performs better. Before assuming the cause, compare what you observe with the common Squarespace SEO mistakes that can create similar symptoms.

This is a diagnostic process, not a launch checklist. If the site is still being configured, use the Squarespace SEO checklist to establish the baseline first. An audit is more useful once there is a live site, real URLs, published content, and enough indexing history to inspect what search engines are doing with the property.

Before reviewing individual pages, make sure you can access the evidence needed to separate a real search problem from a design preference or a generic tool warning:

• Google Search Console: use a property that has at least 30 days of usable search and indexing data so you can inspect URL states and performance patterns.
• Google Analytics 4: or another analytics setup that lets you compare organic landing pages with broader site behavior.
• Squarespace administration: especially the controls for pages, design, and search-related settings.
• A browser inspection tool: use an SEO extension or browser developer tools to verify headings, robots directives, canonical output, links, and rendered page content.

A paid crawler can speed up larger reviews, but it is not required for an initial diagnosis. Manual checks, Search Console evidence, and selected URL inspections can reveal substantial problems on many sites. If the property contains more than 200 pages or has an active publishing archive, a crawler such as Screaming Frog can make comparison work more efficient; its free tier can inspect up to 500 URLs. Use Search Console data as evidence about this site rather than assuming that any published benchmark explains the cause.

Work from dependency to dependency. Confirm that the right pages can be discovered and indexed, then inspect what those pages communicate, how they link together, how they render, and whether their content matches the search demand they are intended to serve.

Start by determining whether Google can reach and index the URLs that matter. If an important page is blocked, excluded, redirected incorrectly, or absent from the index, changing its copy or metadata is unlikely to solve the immediate problem.

Inspect robots.txt

Open yourdomain.com/robots.txt and review what the generated file allows and disallows. Squarespace creates this file for the site, but the audit question is whether any directive prevents access that you actually want search engines to have. Do not interpret every disallow rule as an error; focus on whether important public URLs are affected.

Review Page Indexing in Search Console

In Google Search Console, open the page indexing report and inspect important exclusions by URL rather than treating every status as a sitewide failure. Use URL Inspection when you need the current canonical, crawl state, or indexing information for a specific page.

• Crawled, currently not indexed: investigate whether the page is distinct, useful, internally linked, and intended to be searchable before deciding that the status itself is the problem.
• Duplicate or alternate page: compare Google's selected canonical with the URL you intend search to use. Similar archives, parameters, or duplicate paths may be legitimate or may expose a consolidation issue.
• Discovered, currently not indexed: confirm that the URL is important, reachable through internal links, and included where appropriate before assuming a sitewide crawl-budget problem.

Verify the Sitemap

Squarespace publishes the sitemap at yourdomain.com/sitemap.xml. Confirm that the file loads, that important indexable URLs are represented as expected, and that Search Console can process the submitted sitemap. Sitemap submission helps discovery, but it does not require Google to index every listed page.

Check Page-Level Indexing Controls

Review the Squarespace search visibility settings and inspect important pages for robots directives. A hidden-from-search setting can explain broad visibility problems, while a page-level noindex directive can explain an isolated one. Verify the rendered output instead of assuming that a dashboard setting produced the intended HTML.

At the end of this layer, you should be able to name which important pages are indexable, which are indexed, which are intentionally excluded, and which need further diagnosis. That list becomes the foundation for every later audit decision.

After access and indexing are confirmed, inspect the signals and content structure searchers and search engines encounter on each priority page. The goal is not to force every field to contain a keyword. It is to make the page's topic, purpose, and relationship to the rest of the site clear.

Review Page Titles and Search Snippets

Squarespace provides page-level SEO controls. Compare the configured title and description with the page's actual purpose and the queries it is intended to satisfy. A good audit checks whether the title is descriptive, distinct from other important pages, and useful when read out of context.

• A vague title such as "Services" may fail to explain what the page offers or whom it serves.
• A blank description is not automatically a ranking problem, because Google can generate snippets from page content, but writing a useful description gives you a clearer candidate for relevant searches.
• Repeated titles across genuinely different pages are a cue to inspect whether the site architecture or targeting is too ambiguous.

Inspect Heading Structure

Use headings to reflect the page's information hierarchy rather than to satisfy a mechanical count rule. In Squarespace, verify the rendered headings because visual styling and semantic heading levels are not always the same thing. If the page has a Heading 1, it should clearly describe the main topic. If an intended H1 is styled only as body text, the semantic hierarchy may be unclear. If several sections use H1 styling, confirm that the primary H1 still communicates the page clearly. An extra H1 is not automatically a penalty, and a missing H1 does not by itself explain rankings, but either finding can justify a closer structural review.

Audit Image Alternatives

Review whether meaningful images have useful alternative text and decorative images are handled appropriately. Avoid using file names as a substitute for image descriptions. An auto-generated name such as IMG_4821.jpg tells you little about the image's purpose. The primary reason to write accurate alt text is accessibility, with image search understanding as a secondary consideration.

Trace Internal Links

Open several important service, product, or editorial pages and follow their internal links. Ask whether users can move naturally to closely related information and whether important pages receive contextual links from other relevant pages. An isolated page with no meaningful internal references deserves review, but link quantity by itself is not the objective.

Document each issue at the URL level. A title problem, heading problem, image accessibility problem, and internal-linking problem require different fixes, so do not collapse them into a single generic on-page score.

Squarespace provides hosted infrastructure, SSL, responsive templates, and canonical output, but site owners still control choices that affect rendering and user experience. This audit layer asks whether those choices create measurable performance or usability problems on important pages.

Review Core Web Vitals Evidence

Test the homepage and other high-priority landing pages with Google PageSpeed Insights at pagespeed.web.dev. When field data is available, use it to understand real-user Core Web Vitals; lab data is better treated as diagnostic evidence that can help identify what to investigate.

On a Squarespace page with weak loading performance, inspect the actual cause before prescribing a fix. Common candidates worth checking include:

• Large hero media that becomes the Largest Contentful Paint element and takes too long to render.
• Video backgrounds or embeds that add network and rendering work before the primary content is usable.
• Third-party scripts inserted for analytics, chat, scheduling, advertising, or other functions.

Check Mobile Rendering

Use browser developer tools such as Chrome DevTools with the F12 shortcut to inspect important templates at narrow widths, then test on a real mobile device when possible. Squarespace layouts are responsive, but custom CSS, code blocks, embedded widgets, and long content can still create clipping, overlap, or interaction problems.

Review URL Slugs

Inspect the slug for each priority page and ask whether it is concise, understandable, and stable. An automatically generated slug such as /page-1 may be less descriptive than a meaningful alternative, but changing an established URL is a migration decision, not cosmetic cleanup.

Verify Redirects Before Changing URLs

If a page was renamed, consolidated, or removed, confirm where the old URL now leads. Squarespace URL mappings can be used for redirects, but the audit should verify the live response and destination rather than assuming a mapping is correct. Preserve useful existing URLs unless there is a clear reason to change them.

Performance findings should be tied to observable evidence: the affected template, page element, device context, or response behavior. Avoid converting a generic speed score into a broad conclusion about why the site ranks where it does.

Once the site is accessible and the rendered page structure is sound, evaluate whether each important URL provides enough relevant information to deserve its role in search. This is where an audit moves from technical correctness to usefulness and intent alignment.

Look for Thin or Underdeveloped Pages

A page with fewer than 300 words is not automatically low quality, and a longer page is not automatically better. Use the count as a prompt for review only. Ask whether the page explains the offer, audience, scope, differentiators that can be supported, practical next steps, and the questions a visitor reasonably needs answered.

Choose the important non-homepage pages and compare them with the search intent they are meant to satisfy. A service page can be concise if the decision is simple, while a complex service may need more explanation. Expand content because a useful topic is missing, not because an arbitrary threshold needs to be crossed.

Define a Primary Search Purpose

For each priority URL, state the main query theme or intent in plain language. Then check whether the page title, main heading, introduction, supporting sections, and internal links consistently support that purpose.

• Does the main Heading 1 accurately describe the page?
• Does the opening 100 words make the subject and user problem clear without forced repetition?
• Do the title and description accurately represent what the user will find after clicking?
• Does the body cover closely related questions that belong on the same page rather than unrelated keyword variations?

A page does not need to repeat an exact phrase mechanically. It needs to be unambiguous about what it covers and useful for the search intent it targets.

Check for Overlap and Cannibalization

Compare pages that target similar themes. If several URLs repeatedly appear for the same query, inspect whether they serve genuinely different intents or compete because their scopes are unclear. Search Console performance data can help surface overlapping URLs, but multiple ranking pages are not automatically a problem.

Review Information That Can Become Stale

Update content when facts, offers, examples, availability, policies, or current practices have changed. Do not revise a page merely to create a freshness signal. For material involving pricing, verify that the information still reflects what the page is intended to communicate before leaving it unchanged.

A useful audit does more than identify 20 possible issues. It explains which findings can block discovery or indexing, which affect important landing pages, which are supported by direct evidence, and which are low-risk cleanup items. Prioritization should reflect likely search impact, business importance, dependencies, and implementation effort.

Address Blocking or High-Confidence Issues First

• Remove an unintended sitewide noindex condition if the public site is supposed to appear in search.
• Correct important URLs that return the wrong status, redirect to the wrong destination, or are unintentionally excluded.
• Resolve missing or misleading titles on priority landing pages when they obscure page purpose.
• Fix a confirmed performance bottleneck when evidence ties it to a specific element on a high-value template.
• Add required 301 redirects when an established URL has been permanently replaced by a new destination.

Then Work on High-Value Structural and Content Improvements

• Expand or rewrite pages whose content does not adequately satisfy their intended search purpose.
• Clarify headings and page structure where users or crawlers have difficulty understanding the information hierarchy.
• Differentiate or consolidate overlapping pages after determining whether they serve distinct intents.
• Strengthen contextual internal links so important pages are easier to discover within related content.

Schedule Lower-Risk Cleanup Separately

• Improve missing or weak image alternative text where it affects accessibility or understanding.
• Review secondary slugs only when changing them produces enough benefit to justify redirect and migration work.
• Refresh non-core content when the underlying information is actually stale.

Do not let a low-priority issue displace a problem affecting the site's most important organic landing pages. A remediation list should name the affected URL, the evidence, the proposed change, any dependency, and a way to verify the result after implementation.

If findings span several systems or depend on one another, outside help can be useful for diagnosis and sequencing. That decision should be based on complexity and risk rather than a fixed threshold. For example, a migration problem, overlapping content, and internal-linking changes may need to be planned together so that one fix does not undermine another.