How To Change The Website Design On Squarespace Without Losing SEO Rankings
Squarespace 7.0 and 7.1 handle redesigns through entirely different mechanics: 7.0 lets you install a new template over an existing site, while 7.1 runs every site on one shared codebase with no separate templates to switch between. Design changes alone never affect search rankings; lost rankings after a redesign come from broken URLs, missing metadata, or altered heading structure, not from new fonts or colors. Restyling through Site Styles carries zero SEO risk because it touches nothing structural, rebuilding sections in place carries low risk if slugs and headings stay intact, and full migration to a new site carries the highest risk and is necessary only when the site's information architecture is truly broken. Exporting a full URL list from the sitemap, redirecting anything that changes address, and preserving page titles and descriptions are what keep a redesign from costing traffic. Site Duplication, found under Settings, copies an existing site's pages, metadata, and slugs intact, making it a safer starting point for a redesign than building on a fresh template.
Before you touch a single font setting, check which version of Squarespace you're on. That one detail decides everything about how to change website design on Squarespace: version 7.0 lets you install a different template over your existing site, and 7.1 does not. If you're on 7.1, no amount of digging through the Design panel will surface a template switcher, because there are no separate templates to switch between.
What follows is the full procedure for both versions, plus the part most guides skip: how to move design work onto a live site without tanking the rankings you already have. Redesigning is the easy half. Keeping your URLs, metadata, and redirects intact is where sites get hurt.
Check your Squarespace version in the Design panel
Open your site's admin panel, go to Help, and look for the site version listed there. If that path feels buried, there's a faster tell. In 7.0, the Design panel includes a Template option with a "Install new template" or "Change template" control. In 7.1, Design opens into site-wide styling controls (colors, fonts, buttons, animations) with no template entry at all.
Another quick check: click into any page and try to add a Section. If you get a library of pre-built section layouts with a blue "Add Section" button between blocks, you're on 7.1. Version 7.0 gives you index pages, banner areas, and template-specific behaviors instead.
Why does this matter so much? Because the two versions handle redesigns through completely different mechanics:
| Capability | Squarespace 7.0 | Squarespace 7.1 |
|---|---|---|
| Install a different template | Yes, from the Design panel | Not available |
| Preview before publishing | Yes, template preview mode | Duplicate site instead |
| Site-wide style controls | Varies by template family | Uniform across all sites |
| Section-based page building | Limited, template-dependent | Core to the editor |
| Style Packs / preset palettes | No | Yes |
Squarespace 7.1 unified templates into a single codebase
This is the question almost every forum thread circles without answering. In 7.0, each template was its own codebase with its own rules. A Brine site behaved differently from a Bedford site; navigation, banners, and index pages were wired into the template itself. Switching templates meant swapping the underlying engine, which is why layouts scrambled and settings reset.
Squarespace 7.1 collapsed all of that into one engine. Every 7.1 site runs the same code. What you pick when you start a new site is a starting layout, not a template in the old sense: a set of pre-arranged sections and style presets applied on top of identical machinery. Once you've edited it, there's nothing left to "switch to," because every design the platform offers is already available to you through Site Styles and the section library.
On 7.1 you aren't locked into a template. You're already in the only template, and it can look like almost anything.
That reframes the whole problem. The question stops being "how do I switch?" and becomes "how far do I want to go?" Three paths, roughly.
Three Paths for Changing Website Design on Squarespace Carry Different Time and SEO Costs
Each route costs a different amount of time and carries a different amount of SEO risk. Choose before you start clicking, because switching horses midway is how half-finished sites end up published.
Restyling keeps every URL and page intact
You keep every page, URL, and piece of content. You change colors, fonts, button shapes, spacing, and image treatments through Site Styles. Zero SEO risk, because nothing structural moves. This is the right call when the site works but looks dated, or when your brand has evolved and the site hasn't caught up.
Time: an afternoon to a couple of days. If your issue is that the site feels off-brand rather than broken, the process for getting your brand onto the page without fighting the platform covers the font and palette decisions in more detail than I'll get into here.
Rebuilding sections in place balances effort against risk
Same URLs, same site, new layouts. You delete and rebuild sections page by page, pulling from Squarespace's section library, then restyle on top. Low SEO risk if you keep your page slugs, headings hierarchy, and body copy intact. Medium risk if you also rewrite content, because that changes what Google has indexed.
This is the sweet spot for most redesigns, and it's underused. Most people assume a real visual change requires a rebuild. It doesn't.
Full migration is necessary only for broken information architecture
You create a fresh Squarespace site (or duplicate your existing one), redesign it in private, then move your domain across. Highest effort, highest risk, and sometimes the only sound option, particularly if you're on 7.0 with a template that fights you at every turn, or if your information architecture is wrong rather than just ugly. Structural problems don't get fixed by new fonts.
Not sure which bucket you're in? The seven signals that a Squarespace site has outgrown a refresh are worth running through before you commit to the expensive path.
Fonts and colors cascade from Site Styles to all sections
Open the Design panel. You'll work top-down, because the settings cascade: fonts and colors set globally, then sections inherit them.
- Fonts. Set your heading and body typefaces, then adjust the size scale. Squarespace lets you shift all headings proportionally with one slider rather than editing H1 through H4 separately. If you're using brand typefaces that aren't in the native library, uploading them is simple now; the custom font upload process takes OTF, TTF, and WOFF files.
- Colors. Build your palette, then assign color themes to sections. This is the single most powerful control in 7.1 and the most neglected. One palette change ripples through every button, link, and background on the site.
- Buttons. Shape, size, border weight, fill behavior on hover. Small change, disproportionate effect on how professional a site reads.
- Spacing and site width. Section padding and content width do more for a dated site than any font swap. Cramped vertical spacing is the most reliable giveaway of a 2019 build.
- Images and animations. Set aspect ratio behavior, hover effects, and page-load animation. Pick one animation style and apply it everywhere, or none at all. Mixed animation across sections looks like an accident.
Style Packs are worth a look here too. They apply a coordinated set of font, color, and spacing choices in one click, which is useful as a starting point even if you then override half of it. Treat them as a draft, not a destination.
Squarespace 7.0 template switching scrambles layouts and resets settings
If you're on 7.0, you do get a true switcher. Design → Template → Install New Template. Browse the family list, install, and Squarespace sets the new template to preview mode while your live site stays untouched. You can click around the preview, restyle it, and only publish when you're ready by setting it as live.
Three things to brace for:
- Layouts will scramble. Banner images, index pages, and gallery blocks behave differently across template families. Expect to rebuild page structure, not just restyle it.
- Style settings reset. Your fonts and colors don't carry over cleanly, because each template exposes a different set of style controls.
- Custom CSS will break. Any code targeting template-specific classes stops working the moment the class names change. Save your CSS to a text file before you install anything.
My candid read on 7.0 today is: if you're planning a meaningful redesign anyway, rebuilding on 7.1 is the better investment. You get the section library, better mobile controls, and a platform Squarespace is actively developing. Staying on 7.0 to avoid a migration usually just defers it a year.
Export your URL list before publishing any redesign
Design changes don't hurt rankings. Broken URLs, missing metadata, and dropped page titles do, and redesigns are how all three happen. Run this before you flip anything live.
Export a list of every page, blog post, and product URL currently on your site. Your sitemap at /sitemap.xml gives you the full set. Paste it into a spreadsheet. This list is your contract with Google: every one of those addresses either survives the redesign unchanged, or gets a 301 redirect to its new home.
Then check your metadata. Page titles and descriptions live per-page under Page Settings → SEO, and they are not part of your template or your style settings, which means a restyle leaves them alone but a rebuild on a new site does not. Copy them out.
- URL slugs, keep them identical wherever possible. If you must change one, redirect the old address. The rules for editing a slug safely matter more during a redesign than at any other time.
- Heading hierarchy, one H1 per page, headings in order. Section rebuilds frequently turn an H1 into an H2 or a decorative text block. Check every page you touch.
- Image alt text, replacing an image drops its alt text. Rewrite it as you go, not later.
- Code injection, analytics, verification tags, structured data, chat widgets. All of it lives in Settings → Developer Tools and none of it travels with a new site automatically.
- Redirects you already have, if you've accumulated 301s from a previous migration, they don't copy to a new site. Export them.
The pre-launch SEO checklist I run before any site goes live is the version of this with every box spelled out. Worth running end to end if the redesign touches more than styling.
Site Duplication preserves your URLs and metadata during migration
Nobody covers this part properly, so here's the actual sequence. Duplicating your existing site is almost always better than starting from a blank one: Settings → Site Duplication gives you a copy with your pages, posts, metadata, and slugs intact, which means you redesign on top of your own content instead of rebuilding it.
If you're starting from a fresh template site instead, here's what does and doesn't move:
| Element | How it moves | Effort |
|---|---|---|
| Blog posts | Export as WordPress XML, then import | Low, but check slugs after |
| Static pages | Manual rebuild, copy-paste content | High |
| Products | CSV export and import | Medium, variants need review |
| Forms and submissions | Rebuild forms, export stored data first | Medium |
| Page metadata | Manual re-entry per page | High |
| Code injection | Copy-paste from Developer Tools | Low |
| 301 redirects | Manual re-entry in URL Mappings | Medium |
| Custom CSS | Paste, then debug against new markup | Varies wildly |
Blog post slugs are the trap. The importer sometimes appends a date or changes the collection path, so a post that lived at /blog/my-post lands at /blog/2024/my-post. Compare your old sitemap list against the new one, line by line, and map every mismatch into a redirect. Squarespace supports wildcards in URL Mappings, which saves time when a whole collection path shifted.
On launch day, point the domain, then immediately submit the new sitemap in Google Search Console and crawl your own site with any link checker to catch 404s. Give it a week and check Search Console's coverage report. A handful of errors is normal. A wall of them means a redirect rule is wrong, and the redirect and 404 troubleshooting walkthrough covers the chain and loop problems that cause most of them. The same sequencing logic applies whether you're moving between Squarespace sites or coming in from another platform entirely.
Mobile padding and text sizing require separate review
Squarespace 7.1 gives you separate mobile controls for section padding, text size, and image behavior, and they are easy to forget. Open the mobile view toggle in the editor and walk every page. Look for headline text that wraps awkwardly, buttons that sit too close together to tap cleanly, and sections where the padding you set for desktop leaves an acre of empty space on a phone.
Check the header too. Your logo, navigation, and any announcement bar behave differently at mobile breakpoints, and a redesign that looks sharp on a 27-inch monitor can put a cramped three-line logo above a hamburger menu on an iPhone. Fix it in the mobile-specific settings rather than compromising the desktop layout.
Most redesigns succeed through restyling and section rebuilds
Most people asking how to change website design on Squarespace need a restyle and a section rebuild, not a migration. Colors, typography, spacing, and fresh section layouts will carry a dated site a long way, and you keep every ranking you've earned. Reserve the full rebuild for cases where the site's structure is truly wrong: pages nobody can find, navigation that doesn't match how people buy, content organized around your org chart instead of your customer's question.
If you go that far, do the research before the design. Deciding what the pages should be and who they're for, the way I lay out in this research-first design process, is what separates changing website design on Squarespace that moves the needle from one that just looks newer. And if you want to see what that looks like as a finished build rather than a process, the project portfolio is the shortest route to a straight answer.
FAQ
Can I change my Squarespace template after my site is already built?
On 7.0, yes — Design → Template → Install New Template, with a preview mode so nothing goes live until you say so. On 7.1, there's no template to change, so changing the website design on Squarespace means restyling through Site Styles and rebuilding sections, or duplicating the site and redesigning the copy. Either path gets you to a truly different-looking site.
Will redesigning my Squarespace site hurt my Google rankings?
Only if you change URLs, lose metadata, or break your heading structure. Visual changes alone are invisible to search engines. Keep your slugs, copy your page titles and descriptions across, redirect anything that moves, and rankings hold. Sites that lose traffic after a redesign nearly always lost it to broken addresses, not to new fonts.
How do I preview a new design without publishing it?
Duplicate your site. Settings → Site Duplication creates an unpublished copy on a temporary Squarespace domain with all your content intact. Redesign it freely, share the preview link with whoever needs to approve it, then point your domain at it when you're ready. On 7.0 you can also use the built-in template preview mode, which keeps the live site untouched while you style the new template.
Can I reset my colors and fonts without rebuilding everything?
Yes. Site Styles changes are non-destructive to content — you're editing presentation, not pages. Applying a Style Pack resets font, color, and spacing choices in one move, and you can keep overriding from there. Nothing in the Design panel touches your URLs or metadata.
Should I move from Squarespace 7.0 to 7.1?
If you're already planning significant design work, yes. You get section-based page building, better mobile controls, and the version Squarespace is actively improving. If your 7.0 site performs fine and you only want a lighter touch-up, staying put is reasonable — just know the gap between the two versions keeps widening, and the migration cost doesn't shrink by waiting.
