Do you know that haunting feeling when CMS doesn't work out? Lost content, costly integrations, and endless workarounds can make even the best teams suffer. This spooky season, we'd like to share some CMS horror stories from the Hygraph developers, marketers, and some of our partners so you can avoid common mistakes and rethink how you manage your digital experience.
#Did you mean to publish all the changes?
#But, is CMS versioning the real savior?
#When content modeling goes wrong
Once, I was challenged to solve a project in which the content modeling had gone completely wrong…
It was obvious that the schema and the editor UI had been mixed up. New content was created in the schema, and the schema inputs were used as fields. As a result, there was a collection of content entries in the editor UI as page models.
To fix this, I had to start over and recreate the whole project basically. The good news was that we succeeded despite a lengthy and painful reworking process.
Learn about modeling content with Hygraph
#Never assume, always check
My biggest gotcha in the past months turned out to be quite a trivial rule: "Never assume, always check." There are tons of CMS on the market right now. Many of them use similar approaches and best practices for structuring content, which you may sometimes repeat automatically.
But this could crash your project if you don't double-check whether a "best practice" adopted for one CMS (or even for most of them) is compatible with your particular choice.
#One too many choices
Would you like some help choosing a headless CMS?
Read our comprehensive article to understand the essential parts to check when choosing a CMS and the 5 best headless CMS options.
#API costs
#A traditional approach? Not enough!
At WeFuse, we love a challenge. One of the world's leading automotive brands needed 13 sites in each country of operation. A traditional CMS was too limited for this thirteen-country, multilingual brand project, like cramming a city hatchback, a heavy-duty pickup truck, and a luxurious limousine into a rusty mini-cooper with square wheels.
A headless CMS was exactly what the client needed—it could be customized for every region, offered end-to-end performance and seamless integrations, and allowed the release of new websites within a few weeks when the engine was hot. Now that's a road trip we can all enjoy!
How to successfully move from a monolithic setup to headless?
#The golden(SEO) middle might not be that shiny
My story involves the evergreen battle between the developers and marketing teams and the SEO attempts to get them aligned.
While working at Toggl, and when we decided to move all products under one brand, I was in charge of making sure all domain migrations ran smoothly and because Toggl had its blog on a subdomain and as any well-behaved SEO, this was my chance to get the combined blogs under a subfolder. The good side of it was that all 3 blogs ran on WordPress which made the content migration easy; the bad side was that the new public website was supposed to run on Gatsby (cool, new SSG at the time).
The dev side, rather unhappy to work with the marketing project to begin with didn’t want to hear about WordPress (mainly for the fact that no one was a PHP developer) and the marketing side who wanted WordPress in its full form together with using all the plugins we were using, meaning no headless WP was an option. This left me with the final solution, which was to set up a reverse proxy. In summary, here’s a small insight into the issues we have ran across:
- The WorePress instance was being served from a root domain, and the actual blog from Toggl’s domain was supposed to be shown from a blog subfolder and to solve this we tried probably 10 different things that ended up in redirect loops that caused us headaches for a week at least.
- Given that we would practically have the blog shown on two different domains, we had to hide one from the search engines. Our WP hosting partner told us we needed to set up redirects which again ended up in a redirect loop so we settled in on x-robots header which kept randomly appearing where it shouldn’t be on the production blog until we found a way to permanently strip it on the proxy instance.
- The original setup had pages loading in 500ms - 1s, the new reverse proxy set up brought that to 3-5s
- To fix that, we had to set up a cache for up to 2h which made the marketing team rather unhappy because for updates on the website they may need to wait up to 2h for them to be reflected on the website
- We oversaw the fact that we had a robots.txt file accessible on the domain where our actual blog was hosted and proxied from which caused us to scratch our heads 2 months later when the pages still weren’t being indexed.
The upside was that it eventually worked, and the traffic had doubled (combined blog vs sum of all parts), but at what cost.
#Used the wrong embed code
If you’ve read our previous series on how we use Hygraph for our daily project, you may already know that we use markdown to format our blog, and we defined a series of markdown components to display different elements in our blog visually. The in-line elements are stored in a shared Notion document as code blocks, which I can copy and paste whenever needed. However, we are only human, so sometimes I choose the wrong component and realize it after previewing the post.
For example, we created our own code for embedding YouTube videos instead of using YouTube's embed code directly, so the video would appear differently. We also have note blocks for different kinds of messages: questions, tips, reading recommendations, etc. However, sometimes, I just used my all-time favorite: the editor's note, instead of choosing the most appropriate components.
#Forgot about the publishing date
#Duplicating assets
#Holiday mix-up
#Publishing too soon
I’ve got a light-hearted confession to make about a little CMS incident during our rebrand. Everything was running smoothly as we prepped for launch—until we accidentally hit "publish" on the staging site instead of the production test site.
For a brief (but glorious) moment, the entire world had access to our "Top Secret Page of Meat and Food Jargon", complete with all the delightful captions.
It quickly reverted the changes—but not before our CEO got a notification about the unexpected "food mystery." Thankfully, it was taken with good humor!
Let this be a gentle reminder to double-check your staging content before hitting that publish button. Even the most serious CMS work can sometimes come with unexpected flavors!
#How to avoid CMS horrors/mistakes
This wouldn’t be a Hygraph kind of a story if we only stopped at all the laughter. Certainly, it’s that time of the year to gather around spooky stories, but we all want to avoid common mistakes when working with a CMS. Based on these stories, we have some thoughts about avoiding CMS horrors.
Double-check before publishing
Many CMS horror stories are light-hearted, but they can be easily avoided if you are careful: Always hit the “save” button before publishing, double-check before hitting the “publish” button, and set up a solid workflow for publishing content set the tone for how you use your CMS.
It is also important to review the content right after it has been published. Your website is merely an “out of sight, out of mind” task. Take a look at what's been published and you are still in time to cover most of the errors.
Learn best practices
Because there’s no single answer to how you should use your CMS, many times, we learn how to make the most of our CMS by looking at best practices from others. For example, a company-wide taxonomy system can help locate all assets in your CMS and avoid asset duplicates, and learning from case studies and tutorials can help equip you with the necessary knowledge of how you should conduct your tech stack.
Never assume, learn your own case
Indeed, as our partner, Anastasiia Zubkova from Bejamas, mentioned, you should never assume. Just because one piece of advice works on one setup, it doesn’t mean it’d necessarily work for you. Most importantly, you should know clearly what you want to achieve with your project. Think twice before following the crowd. It's the same when it comes to your tech stack: don't just buy it because people rave about it. Think about whether the fancy features are actually going to help your use case, and don't just use WordPress or Wix just because others use them.(Just read our article to see how flawed they are.)
Furthermore, if you have selected a SaaS solution, your vendor will have your best interest at heart, so proactively communicating with them is important. SaaS vendors want you to have the best user experience, so they will surely help if you have trouble. When did you last jump into a check-up call with your CMS vendor and say everything is fine, just because you needed a little time to focus on your release? It might be possible to get your release out much more quickly if you have actually prepared for the call and asked for some help.
Plan and monitor your costs
Your project doesn't end after you purchase a CMS solution, but rather it begins with a whole new adventure, which is why you need to plan and monitor how you use your new CMS. You should know roughly how much extra spending you'll have with the integrations and IT costs at the beginning of your project. Keeping an eye on the costs will help you keep a better handle on them.
#Final words
Did these stories give you a chill? Despite sounding lighthearted, the stories can provide valuable lessons. It is always best practice to double-check before publishing, keep an eye on costs, and work closely with your team. Hopefully, you enjoyed reading the stories from peers in the CMS industry and can avoid similar mistakes after reading this article. If you have questions or doubts about how to properly use your CMS, Hygraph is always here to help.