Blocksy to Next.js: Moving the Customizer, Content Blocks and Shop Extras

Four products, one name: where a Blocksy site keeps its parts

A Blocksy site is rarely just Blocksy. The theme draws the page and holds the Customizer. The free Blocksy Companion plugin, with its own 300,000+ installs, supplies many of the features people credit to the theme. Blocksy Pro adds extensions on top of Companion. And on a store, WooCommerce brings its own data plus whatever Shop Extra switched on. A migration has to account for all four, because each stores its work in a different place.

The good news is that most Blocksy content is ordinary block-editor content. Blocksy was built for Gutenberg, so a typical post is core blocks wrapped around text and images. That converts cleanly into structured fields. The exception is a site that started from a starter site tagged Elementor, in which case the page bodies are Elementor data and the Elementor to Next.js guide applies to the content, while this page covers the Blocksy shell around it.

Export the Customizer, then treat the file as evidence

Open Customizer, General Options, Manage Options and click Export Options. Blocksy writes your whole Customizer configuration to a file. Note the catch in Blocksy's own docs: Export, Import and Copy Options only appear when Blocksy Companion is active. If someone deactivated Companion to chase a bug, turn it back on first, or you will see nothing but Reset Options, which is the one button you should not press.

Next.js cannot import that file, and it should not try. It is a record of decisions: the exact hex values, the font stack, container widths, button radius, the header rows and which elements sit in each. We read it the way an accountant reads last year's ledger, then write the values into the project as CSS custom properties. Colors become tokens. Fonts move to next/font, which serves them from your own domain without a Pro extension to pay for.

Take screenshots too, at desktop width and below 1,000 pixels. Blocksy's CSS switches to the mobile header under 1000px and uses 689.98px as its mobile breakpoint, with no setting to change either. In the new build you pick breakpoints that suit your design rather than the theme's defaults. If your current mobile header already misbehaves, the Blocksy mobile menu fix explains why, and the rebuild retires the cause.

Content Blocks: the half of the site that hides from the Pages list

Content Blocks are where Blocksy migrations go wrong, because they do not appear under Pages or Posts. They are a separate post type, and each one carries rules: a hook position, display conditions by page or post type, user-role conditions, sometimes an expiry time or fixed positioning. A banner that appears only for logged-out visitors on product pages until Friday is invisible until you go looking.

So we go looking. Every Content Block gets a row in the inventory: its type, where it shows, who sees it and when it stops. Blocksy uses this system for hooks, pop-ups, custom 404 pages, single and archive templates, and maintenance mode, so the list is often longer than the owner expects. We also search the database for the blocksy-content-block shortcode. Any copy pasted into a post body would print as raw text on the new site if nobody caught it.

• Hooks become components placed in the right layout. A block shown on every post becomes part of the post template; one shown on three pages becomes a field those pages can switch on.
• Expiry dates become a scheduled end date in Athena. Seasonal offers are a job for Demeter, and banners tied to live events are a job for Zeus.
• Pop-ups get a hard look. Many exist because a plugin made them easy. We keep the ones with a measurable purpose and rebuild them without layout shift.
• Custom 404 and archive templates become ordinary routes in the App Router, written once and tested in the build.

Posts move easily; Post Types Extra needs a field map

Posts and pages come out through the WordPress REST API with their block markup intact. Core blocks convert to clean HTML or to structured fields in Athena, and images are pulled, renamed and resized along the way, as the images migration guide describes. A blog with years of archives follows the WordPress blog to Next.js plan, which also covers categories, tags and author pages.

Custom post types need more care. Blocksy does not create post types itself; it detects ones registered by plugins and adds Customizer panels for their archives and single views. The data belongs to whichever plugin registered it. Post Types Extra then pulls custom fields from ACF, Meta Box, Pods, Toolset, JetEngine or ACPT into post meta layers. We export those field values, map each one to a typed field in Athena, and rebuild the archive cards to show the same information.

The rest of Post Types Extra is simpler than it looks. Read time is calculated at build from word count. Taxonomy featured images and colors become fields on each category. The posts filter becomes a filter on a statically generated archive, which is faster than a filter querying the database on every click.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Stores built on Blocksy and Shop Extra

A Blocksy shop is the heaviest move, and the theme is not why. Products, variations, customers, orders and subscriptions all live in WooCommerce, and they need a new home before anything else. The WooCommerce to Next.js guide covers that data move in detail. On top sit the Shop Extra features from the Business plan: quick view, the floating add-to-cart bar, off-canvas filters and cart, the gallery thumbnail slider and the wishlist.

In a custom build, each of those becomes a component written for your products rather than for every store at once. Not all of them deserve the trip. One shop leans on its wishlist and never uses quick view; another is the reverse. We check analytics before deciding what to rebuild. If the 2.1.50 release broke your single product layout, as it did for some shops, the WooCommerce layout fix for Blocksy will hold you while the new store is built.

Eight moves from a Blocksy site to a Next.js build

1. 1

   Freeze the inventory

   Export Customizer options, list every plugin, every Content Block with its conditions, every menu and every custom post type. Note which Pro extensions are switched on in the Blocksy dashboard.

2. 2

   Crawl the live site

   Collect every URL, title, meta description, canonical and status code, including category, tag, author, paginated and custom post type archives.

3. 3

   Export content and fields

   Pull posts, pages and products through the REST API, plus custom field values and taxonomy images, into a staging dataset we can check line by line.

4. 4

   Write the design tokens

   Turn Customizer colors, type and spacing into CSS variables, and set fonts with next/font.

5. 5

   Build the shell

   Header, mobile menu, footer and navigation as components, checked against your screenshots at every width.

6. 6

   Rebuild templates and Content Blocks

   Single, archive, 404 and product templates first, then each Content Block that survived the review.

7. 7

   Map and test redirects

   Every old URL is kept or sent to its new address with a permanent redirect, and the full list is tested before launch.

8. 8

   Switch and watch

   Move DNS, submit the sitemap, and watch Search Console and server logs for errors in the weeks that follow.

Rankings, redirects and the URLs Blocksy never showed you

Blocksy itself adds few URLs. The ones that bite come from WordPress and its plugins: paginated archives at /page/2/, attachment pages, feeds, author archives, and archives for every custom post type. A crawl of the live site finds them all. The URL structure guide explains which to keep exactly and which to fold into better pages, and the redirects guide covers how they are written in code and tested before launch.

Titles and descriptions usually live in an SEO plugin, not the theme, so we export them from there and attach them to the matching pages in Athena. Structured data is rewritten per page type instead of inherited from a plugin. The full checklist is in migrating without losing SEO. We keep your URLs and redirect every old one.

The Customizer export is not a migration file. It is a list of promises the new site has to keep.

What sets the timeline, and who edits the site afterward

Three things move a Blocksy quote more than anything else: the number of Content Blocks and conditional headers, the depth of the store, and how many custom post types carry their own fields. A brochure site with one header and a blog is a modest job. A shop with conditional headers, a dozen hooks and three post types is a bigger one. The migration timeline guide and the cost guide explain how those drivers add up. We give a fixed quote after a free site audit, and financing is available.

Keep the old site patched until switch day. The update that broke a Blocksy site is still possible while it is live, and agencies already watch Blocksy's appearances in weekly vulnerability lists. On a lifetime license there is nothing to cancel afterward. On a yearly plan, simply let it lapse once the new site is live.

Afterward, your team edits in Athena CMS: plain fields, a real preview and every version kept. There is no Customizer to break and no Companion update to wait for. Argus watches for broken links and failing forms, Aegis checks daily for intrusions, Iris keeps titles and social cards in order, and Picasso makes sure no image goes up unsized. Still weighing the move? Compare first in Blocksy vs Next.js, read how the theme performs today on the Blocksy speed page, or see the Next.js development service and the rest of the WordPress to Next.js section.