Rebuilding a WordPress site on Storyblok, worth adding personalization during the migration?
So after fifteen years of WordPress this is my first headless build, we are rebuilding a client site on Storyblok and honestly it already feels like a different world coming from the plugin ecosystem. The old site ran A/B tests through a client-side plugin and every test flashed the original page before swapping, client complained about it constantly and I never had a real fix.
My question is about sequencing, do I wire personalization into the Storyblok rebuild now while everything is fresh, or ship the rebuild first and bolt testing on later like I always did with WordPress plugins? Feels like the answer might be different in headless land but I dont know the tradeoffs yet
2 answers
The nice part of the model is that this is not really an either-or decision the way it was with WordPress plugins.
Croct's Storyblok integration is an overlay: your blocks stay exactly as you build them in the rebuild, and enabling personalization on a block means adding a Croct field to it and connecting it to a matching slot. Nothing about the rebuild architecture changes based on when you do that. So you can ship the rebuild first and "bolt on" testing later without any of the retrofit pain you are used to, the blocks are already the right shape.
That said, I would map one or two high-traffic blocks during the rebuild anyway, homepage hero is the classic pick. Gradual adoption is the intended path: everything unmapped renders straight from Storyblok, so two mapped blocks do not commit you to anything site-wide, and your client sees testing working on day one of the new site.
On the flashing: that goes away structurally. Content is resolved server-side, so experiences load with no flash of default content. It is not a mitigation of the swap, there is simply no client-side swap in the architecture.
The gradual thing is what sells it for me, in WordPress land bolting on later always meant rework so I assumed the same here. Hero block it is, thanks Sophie
Did the same WP-to-Storyblok jump last year. One practical tip: decide your block schemas with the mapping in mind even for blocks you will not map yet. Keeping the copy your client will want to test (headlines, CTAs) in their own fields rather than buried in one big rich text field makes the later mapping trivial. Costs nothing during the rebuild and saves a schema change later.