Squarespace to WordPress: A Migration Built to Protect Years of SEO – NoKillMag

Project Overview

No Kill Mag publishes at the intersection of fashion and sustainability. Its sections — Designers + New Materials, Secondhand + Style, Culture++ and Shop Better — serve a readership that ranges from design students to conscious shoppers looking for practical guidance on where to buy vintage or how to quit synthetic fabrics.

That mix matters. Interviews with emerging designers earn attention when they’re published; shopping guides earn it for years afterward. Public SEO data reflects this: the pages drawing the most organic traffic today are evergreen guides published deep in the archive, not the newest features. For a publication like this, the website isn’t a brochure. It’s the product — and the back catalog is a working asset that keeps producing.

The site also carries the editorial workflow itself. A small team publishes regularly, manages categories, curates related reading and maintains a newsletter audience. Anything that slows the editors down slows the magazine down.

Business Goals

The brief was never “rebuild the website.” It was closer to “make sure years of work survive, then make the next years easier.”

That translated into five objectives. Move off a platform whose editing limitations and bugs had started costing editorial time. Protect every published article — the archive is where most of the magazine’s search traffic lives. Give editors a CMS they could run without a developer on call. Preserve the search visibility the publication had accumulated, because rankings built over years can be lost in an afternoon of careless redirects. And leave behind a structure that can absorb the next 400 articles as comfortably as the first.

A magazine’s credibility with search engines compounds slowly. Domain authority, referring links from other publications, rankings on competitive terms — none of it transfers automatically when a site changes platforms. The migration had to treat that accumulated trust as the most valuable thing being moved.

Challenges

Four hundred articles is not a large number for a script. It’s a large number for a publication, because every one of them is a page some reader, search engine or external site already knows how to find.

Each article carried its own URL, its own metadata, its own images and its own internal links to other articles. A migration that got 95% of this right would still break twenty pages — and there’s no way to know in advance which twenty pages carry rankings that took years to earn. Public data shows the domain ranking for roughly fifteen thousand keywords in the US, with thousands of external sites linking in. Most of those links point at individual articles, not the homepage. Break the URLs and the links break with them.

The visual identity added a second constraint. The client liked how the magazine looked. The redesign brief was, effectively, don’t redesign — recreate the existing design on an entirely different rendering system, closely enough that returning readers notice nothing except that pages load faster.

Then there was search. On the old platform, on-site search performed poorly enough that it had been removed from the interface. For a publication whose value is concentrated in its archive, that’s a quiet but real business problem: readers can’t discover what they can’t search.

And underneath everything, performance. Page speed shapes how long people read, how deep they scroll and how search engines evaluate the site. The old platform offered little room to tune it.

Migration Strategy

The migration was planned backwards from a single requirement: the day after launch, every existing URL must respond exactly as it did the day before.

We began with a full inventory. Every article, page, image and internal link on the Squarespace site was catalogued before anything was built. This inventory became the contract for the whole project — the checklist against which the new site would be verified. Migrations fail when the team discovers content after launch; the inventory made that impossible.

Content came next. All 400+ articles were moved into WordPress with their publication dates, authors, categories, images and formatting intact. Internal links between articles were checked and repointed where the platforms’ URL conventions differed, so the web of related reading the editors had built over years kept working.

URL preservation was handled at the structure level rather than with a blanket of redirects. Where the existing path could be reproduced natively in WordPress, it was — a page that keeps its address keeps its history cleanly, with no redirect chain for crawlers to re-evaluate. This is the difference between a search engine seeing the same site on a faster platform and seeing a new site that vaguely resembles an old one.

SEO metadata moved with the content. Page titles, meta descriptions and social sharing tags were carried over article by article, because those fields are where years of deliberate search optimization actually live. Losing them wouldn’t break any pages; it would quietly reset the work.

Before launch, the complete site was tested against the original inventory: URL by URL, checking response codes, titles, metadata and rendering across devices. The cutover itself was staged so the switch was reversible until verification finished. Nobody should discover a migration problem from a Google Search Console alert.

Design & Development

The new site was built on WordPress with Astra as the technical foundation, customized to reproduce the magazine’s existing design.

Astra was a deliberate choice rather than a default. It’s lightweight enough not to fight the performance goals, widely maintained enough that updates arrive for years without developer intervention, and flexible enough to be shaped into the client’s design rather than imposing its own. For a publication that needs its platform to outlast any single engagement, building on something proven and actively maintained lowers long-term risk in a way a fully bespoke theme rarely does.

The client’s visual identity — layout, typography, the rhythm of the article pages — was recreated on top of that foundation with custom CSS and JavaScript. There’s a version of this project where the migration becomes an excuse for a redesign. We argued against it. Readers had years of familiarity with how No Kill Mag looks and navigates; keeping that intact meant the platform change was invisible to the audience, which is exactly what a platform change should be.

The responsive implementation was rebuilt rather than approximated. Editorial sites live and die on mobile reading, and article pages, image galleries and category archives were tested across breakpoints so the reading experience holds up on a phone as well as a desktop.

Performance work ran through the whole build rather than being bolted on at the end: image handling, asset loading, caching and a theme choice that kept the page weight low from the start.

Editorial Experience

The most important user of this website isn’t a reader. It’s the editor who works in it every day.

On WordPress, the team writes and publishes in an interface built for editorial work. Categories, tags, featured images, scheduling and revisions behave predictably. The platform limitations that had made routine edits frustrating on Squarespace simply stopped being part of the workflow. When editors trust their tools, they publish more and troubleshoot less — that’s the entire return on this part of the investment.

Search came back. On-site search now works well enough to be visible in the navigation again, which matters more for No Kill Mag than for most sites: with hundreds of articles, the archive is where the depth is, and search is how readers reach it. Custom filters extend the same idea, letting readers narrow the archive rather than scroll through it.

The category structure — Designers + New Materials, Secondhand + Style, Culture++, Shop Better — was preserved and wired into clean archive pages, related-article modules and trending lists. Every article now actively points readers toward the next one. For a publication whose older guides still earn the majority of its organic traffic, keeping readers moving through the archive is a direct business function, not a design flourish.

Performance & Optimization

The site runs on cloud server infrastructure sized for a publication rather than a generic shared host, with caching and Cloudflare in front of it.

Performance was measured throughout the build with Google PageSpeed, GTmetrix and Pingdom, and tuned until the results were consistently strong across all three — a significant improvement over the Squarespace site it replaced. Image optimization, careful asset loading and Astra’s low base weight did most of the work; the infrastructure did the rest.

Speed is an editorial concern dressed up as a technical one. Faster pages keep readers in an article to the end, make browsing the archive feel effortless, and feed into how search engines rank the site. On mobile — where much of a fashion publication’s audience reads — the difference is immediate.

Security

A publishing site with steady traffic and years of accumulated authority is a target precisely because of that authority, so security was layered rather than left to a single plugin.

Cloudflare sits in front of the site, absorbing malicious traffic before it reaches the server. SSL encrypts every connection — table stakes for reader trust and for search engines. At the application level, Wordfence and WP Hardened monitor and lock down WordPress itself, while a server firewall closes off everything the site doesn’t need exposed. reCAPTCHA keeps automated abuse out of the forms.

For a magazine, the cost of a compromise isn’t just downtime. It’s a warning label in search results, blacklisted URLs and damage to exactly the search reputation this migration was designed to protect. The security setup exists so the editors never have to think about any of that.

Technology Stack

WordPress was the right platform because it’s built around the thing this client does all day: publishing. Its editorial tooling, category system and ecosystem maturity fit a magazine’s workflow without customization for its own sake, and its ubiquity means the client is never locked into one developer. Astra, customized with PHP, CSS and JavaScript, provided a fast, actively maintained base that could carry the client’s existing design without the fragility of a fully bespoke theme. Every piece was chosen for how it would behave in year three, not just at launch.

Outcome

All 400+ articles made the move with their URLs, metadata and internal links intact. The site’s search visibility carried through the transition — public SEO data today shows the domain holding rankings across thousands of keywords, with long-published archive guides still among its strongest pages. That continuity was the point: the articles that earned their positions over years kept them.

The editors now work on a platform that behaves like a publishing tool instead of an obstacle. Search is back in front of readers. The site is measurably faster than what it replaced, secured in depth, and built on components that will keep receiving updates for years.

The magazine looks the way its readers expect. Underneath, almost everything changed.