You have just landed on this article, and there are several reasons for that:
In this article, we will cover how our marketing team uses Strapi daily to manage the content of our website because yes, in case you did not know, strapi.io is made with Strapi and The React Framework for Production: Next.js.
On the menu for this article: Customization, SEO, Preview, Landing Pages, Webhooks, Collaboration, and just about everything you need to unleash your creativity. Let's start without further delay!
Eh! Where are you going?
You will understand why, from a marketer's point of view, Strapi has a lot of advantages. In case you did not know, Strapi is a headless CMS that is:
But why is this an advantage for the marketing team?
We work daily to facilitate the developer experience and ensure that they can build a Strapi application that is: customizable, well-structured, scalable, quick, and easy so that you can manage the content in a fluid and flexible way.
It would be great to have an example of a company using Strapi to manage its content...
We rebuilt our website a year ago and decided to use Strapi for the Backend (obviously) and Next.js for the front end. It was made by the Web agency Unlikely.
Our Marketing team has the same needs that many of our customers have, so writing this article was quite easy. Here are the most important topics:
Customization is, without a doubt, Strapi's biggest advantage.
Indeed, assume that you can do almost anything on your Strapi application. Do you want to change the default WYSIWYG editor? Go ahead, it's entirely possible. Do you want to include a guided tour in the admin to onboard your content managers? We did that on our FoodAdvisor demo app. Do you want to be able to schedule the publication of your content? Create a publish_at
field and insert a custom code using the cron feature to publish your data. This might be too technical for you, so I will let your engineers follow the guide for this use case: Schedule publication in Strapi.
You own the code. I mean not you or your developers, but I want to say that we offer the flexibility to do whatever you want with your Headless CMS.
With FoodAdvisor, I included a Preview button in the content manager and created a guided tour plugin using react-tour package. Without it, I would have had to wait for these features to be released.
This is what we mean when we define ourselves as a product that can Unleash Creativity. We put in your hands a customizable product, you do the rest, and the community will be there to help you.
Before I talk about SEO, I have to tell you something. I try to provide as many answers to simple questions in the Strapi community's mind or potential users to reassure them that Strapi can solve their project.
Many use Strapi without knowing exactly what it is or how it works. There was a time when many of them asked us the following question: Can I use Strapi with (x frontend framework/programming language) like React, Angular, Ionic, Python? The answer is yes since Strapi is a CMS that allows you to consume its content via an API. If you use a technology that allows you to perform HTTP requests, then yes, you can use Strapi as your data source. I wrote an article about it: Integrate Strapi with everything.
I also created several integration pages on the website as well as documentation pages containing actual examples of connections with various frontend frameworks/programming languages.
And you know what? Nobody asks this question anymore, or at least not directly to me. I am happy because I know that users now understand a little better what Strapi is and how it works (but I'm sad because no one speaks to me now...)
Why am I talking about this?
Well, the SEO topic is the same thing. Many of you ask if using Strapi is SEO Friendly for your website/application. The answer is yes, yes, yes, yes, and yes.
So I will once again try to create useful resources on our website to prove to you that yes, Strapi is SEO friendly, although it does depend on you!
For example, you want to list articles on your application. You will probably have a collection-type article
that will contain various fields:
title
(text)description
(longtext)image
(media) etc...Now, consider that each article in your Strapi application will have its page on the front end. Well, for this page to be SEO Friendly, you will need to implement the necessary fields like a meta-title, meta-description, meta-image, or a boolean (true/false) for indexing the page or not. Don't forget to set rules like a character limitation for your meta-title and meta-description fields.
It's not more complicated than that! Do not forget Strapi allows you to create and manage the data your frontend will receive. The biggest work here is to think about the architecture of your data from the beginning to avoid your technical team iterating several times on it. It is, therefore, a question of planning with your developers, what fields you will need for the SEO; your developers will take care to implement them in Strapi. You can, for example, see with your technical team how you can automatically fill a structured data JSON field when creating your content.
Disclaimer: Your front end and only your front end will be the application that will need to perform on Google search results. Strapi will provide the data for your front end through its API. Many people think that the SEO of the Strapi application is important. Unless you want your CMS to rank on search results, which is a terrible idea, the SEO performance of your Strapi application doesn't matter. And therefore, the fact that Strapi is made using JavaScript does not constitute a disadvantage for your website. However, Javascript leads to faster API response times which, together with static site generators frontend, can lead to a lightning-fast website which is important for SEO.
I encourage you to send this article that I wrote to your technical team concerning some good SEO practices in Strapi. These are just basics; feel free to go further with your customization level. These are best practices that we have applied for our website as well as on Foodadvisor, our live demo.
According to SEMRush, our website health is 7% above other sites in our category 😎 This figure is based on the total number of errors and the number of warnings found on the pages by crawling through our website.
Creating landing pages is very important for any marketing team, and this is possible with Strapi. Indeed, a collection type can represent any data for your application, it can be an article, a product, a category, or even a page.
Let's go back to the example used above. You want to list articles on your website. You will therefore have a page listing these articles and a page for each. This logic and architecture will be done at the frontend level, no need to go into details, your engineering leader knows 😉
However, say you want more generic pages like an /about-us, /pricing, or a /contact page. To do that, it's very simple, you just need to create a Page
collection-type. This will allow you, as for articles, to create several pages according to your needs.
Note: We are calling it Page
in this article but feel free to call it whatever you want.
Here are a list of some of our landing pages on our website:
Feel free to visit them by prefixing the slug with https://strapi.io/
Here is a list of 56 components that can be included on each one of our pages.
It is at this precise moment that I must tell you about the very powerful feature in Strapi that makes all of this possible: The Dynamic Zones.
This feature has scared a few. What is it exactly? What is it used for, and how does it work? Let's try to cover all these questions!
Before addressing the Dynamic Zones, I must, first of all, tell you about two things:
When you create any content-type in Strapi, you define the fields it will contain. It's simple, for an article collection-type you will have, for example:
title
(text)description
(longtext)image
(media) etc...It turns out that we, developers, don't like to repeat ourselves at all. So when we create a product, we also ensure that the people who will use it will not repeat themselves. This is why we created components.
A component is a set of fields that can be used in any content-type. Let's say your Article and Category collection-types both share meta-title (text), meta-description (longtext), and meta-image (media) fields. Then it would be preferable for you to create a component containing these 3 fields named SEO. You can then use it for your two collection-types. This means you don't have to repeat yourself! Convenient right?
When you include a component in a content-type it will automatically be included. It may sound weird but once added, it will always be there. So for the example of the SEO component, it's perfect since we always need it for those content-types, so there is no problem. But what if you want to include a component and sometimes don't want to? Do you see the transition coming?
A Dynamic Zone is made up of "blocks" that allow you to include a specific set of components in a content type.
Let's say that I was to delete the SEO component of the Article collection-type previously created, and I wanted to have the option to either include it or not in certain articles.
To do this, I can create a Dynamic Zone in the Article collection-type and include the SEO component. If I go to any article, a little "+" button appears at the bottom of the content manager page. I have to click on it to create a new "block" and select my SEO component. Then, I need to fill in the fields for my article to be SEO-friendly.
This is what a Dynamic Zone is used for: dynamically include components in your content-types. That's it. - Me
Now, imagine a Page
collection-type that contains a Dynamic Zone which includes components such as:
Well, that's exactly what we have on our own website. (I'm not kidding, feel free to check our homepage).
We use Dynamic Zones to generate particular sections of our pages. It allows us to have the option to include or not or not specific components depending on the page. This way, you can see that even if most of our pages are part of a Page
collection-type, they don't display the same content or components.
This exact system is on FoodAdvisor with components such as:
The pricing page also has a Dynamic Zone, but you can include different components, such as Pricing Cards.
I hope that the Dynamic Zone has no more secrets for you. If this feature convinces you, share the message with us on Twitter with the #StrapiDynamicZones 🐦
A tutorial on how to create landing pages using Strapi is coming soon 😉
The preview system allows us to visualize content before it is published. As you know, Strapi is a Headless CMS. It means that we do not generate pages for your data. In fact, it waits patiently at the edge of a beautiful lake to be fetched by a React, Python, or Ionic application. We are almost certain that your technical team has already developed a nice frontend ready to consume this data.
There is, therefore no native functionality allowing you to view your new article on your front since they are not connected by default. This connection must be created, but I guarantee you, it is extremely simple; at least I know that your technical team can do it while drinking coffee.
Here is a tutorial on How to Implement Previews with Next Applications using a Strapi backend that will surely be very useful to your engineers.
However, I told you that Strapi is largely customizable. I did not lie! It is quite possible to include a preview button in the content manager, allowing you to open a page of your front in preview mode. This is a system that is currently in place on our FoodAdvisor demo.
Can you see the Preview button on the bottom right card? This will open this page on my Next.js frontend:
This demo isn't half bad!
I hope I haven't scared you away with this one. If you don't know what it is, a webhook allows you to send information to another application when a particular event occurs. In Strapi, you can send a webhook to Zapier, for example, when you publish, create, edit or delete a piece of content.
You can, for example, set a webhook to publish a tweet via Zapier when you create a new article in your Strapi application. The possibilities are endless, only your imagination is the barrier.
This one is for your CTO: It is possible to use webhooks to build your static site generator when you publish data or simply by manually activating the webhook. This is exactly what we do at Strapi. A webhook allows us to build our Next.js site on Vercel directly from the Strapi admin, so our team can decide when we refresh the website's content.
Thanks to the roles in Role Based Access Control feature, it's possible to set up a collaboration system between the different members of your teams. You can manage the reading, editing, and publishing rights to your Strapi Admin Interface. Review and publish drafts and share access only to the necessary content.
Here is what the interface of a Super Admin looks like:
Here is what an author user will see according to the permissions that will be attributed to him by the Super Admin:
This allows you to align roles with the organizational workflow and help your team do their job more efficiently and autonomously. Feel free to read our user story of how Continuum delivered a corporate website for Banco Internacional with 30 custom roles
An easy way to start implementing an approval workflow process within Strapi could be to disable the Draft & Publish native feature and add a "State" enumeration field in a "Settings" components, mandatory in all new entries, that lists the different states of your content.
Once the article is saved, a trigger is activated, so the content moves to the new state. And the Team that has the rights can now access that piece of content.
Strapi's RBAC feature is deep (thanks to the 'custom conditions') enough to allow specific users to move content only to a specific state. For example, the "Approval Team" can be the only team allowed to push the content in the "rejected state".
I redirect your engineers to a project that one of our Solution Engineer, Derrick Mehaffy did to show two different methods for more complex draft workflows.
We have always published articles more or less oriented to developers because they are the ones who use Strapi in the first place. It is very easy for them to understand the advantages and disadvantages of Strapi, and we can communicate using code blocks. However, this is less the case for members of marketing or growth teams. That's why I wanted to write this piece of content to answer the questions that non-tech people have about the most requested topics.
Our Marketing team uses Strapi with all the features showcased in this article. We use it because it is simple, fast, convenient, and beautiful, allowing us to easily create content for our website. We are confident that it is SEO friendly; we can create pages on the fly and dynamically define which content will live on these pages. We have different environments (staging & production) to help us improve our deployment experience, and we can publish new content in less than 3 minutes.
If you want a taste of what we can do with Strapi, browse our website! The data comes from Strapi, and the design comes from a Next.js application. We are thinking about open-sourcing it soon. You are currently on our blog; continue your journey by discovering our showcase, our user stories, and our career page (we are recruiting).
Give a try to our brand new FoodAdvisor demo application or feel free to contact a member of the sales team if you need more information or a personalized demo. I wish you an excellent day and see you in a future article.
Maxime started to code in 2015 and quickly joined the Growth team of Strapi. He particularly likes to create useful content for the awesome Strapi community. Send him a meme on Twitter to make his day: @MaxCastres