SeoToolkit is a package to easily add SEO capabilities to your website. It actually consists of multiple packages, so that everyone can pick and choose their own functionalities that they need. Maybe someone already has a sitemap implementation, then they can easily not use the one shipped with the SeoToolkit package.
The main functionalities of the SeoToolkit are as follows:
The idea for SeoToolkit started one day while working on a new website. I was mostly done and there was still enough time left for testing the website and fixing any issues that would arise. But then I looked at the tab name and it read "TODO". Of course, I forgot to implement the SEO features. I went to work on adding the logic for meta tags, sitemap and robots.txt. But after that, I was like "I've done this a dozen times now and it is as boring as the last time. There must be a better way!". And just like that, an idea to make my life easier started.
Another motivation to start on an SEO package was because of client feedback. I would usually implement meta fields as a field in Umbraco that would also fall back to several other fields that would make sense to me. However, the clients didn't really use the Umbraco SEO fields and mostly relied on the fallbacks to their normal content. Which is totally fine! But then I would get the feedback that the fallbacks weren't correct and if I could change them. I could but that would take development time. And by saying that, I felt how programmer-focused I was on those solutions. While it wouldn't make sense for the client to change their fallbacks all the time, it would make sense to do that without any deployments. And an interface to show the actual results of those fallbacks would be a great benefit as well.
The idea was that if I could create a package containing SEO features that I would generally want to include in the website, I would have more time to implement/improve the website. While at the same time, I would be providing the clients with a module that they could use and that could be iterated on for each client. Maybe I spend X amount of time on it for every new client. The new features that come out of it could then also be used by any other installations. Along with that, I would be providing extra functionalities to the client without having to spend any time on it. I am sure that the clients would love that.
So, I got my idea and I got my motivation and I started to get to work in my free time. I started on Umbraco v8 at the time but quickly moved to v9 as I figured I would only use this on the newer clients and I just liked .NET Core a lot more.
I started to code some of the meta field features and was able to make some headway, but also got stuck thinking about some good architecture as well. While the idea was simple, the execution was quite difficult as I wanted to reuse Umbraco-specific properties. In the end, I did manage to get it to work.
But then I thought, why stop at the meta fields? Why not add a sitemap, a robots.txt? All the things I would have to create myself and maybe a little bit more as a special surprise to the clients. I would only have to create it once.
Architecture
But then the architecture of the package came up again. Would I want to create one big package or multiple smaller packages that could work together under a special package?
I could see the benefits of both of those ways. A big package is easier to show off to newer clients and is just less confusing in general. However, you are also locked to all the functionality. Maybe you don't want to use the sitemap logic, well bad luck to you!
And on the other side, you had the smaller packages. They would be more work to maintain and it could be a bit more confusing to work with them as you have to figure out what each of them does. But it also gives you flexibility. Maybe someone only wants to use the robots.txt functionality, this way they would be able to do that.
In the end, there was only one way to decide on this. The community. So I asked them what they thought of it through a poll. The majority of the votes were for smaller packages, so that is what I went for.
After building all of the packages, it is indeed a lot more work to maintain multiple packages across multiple versions. But I can see in the Nuget downloads that they are people using only the sitemap or the robots.txt package, so I am very happy to see that happen.
Although if I had gone the paid package road with this package, I think I might have gone with the big package. In that case, do I really value flexibility over time? It is hard to say and I still think that both options would have been fine.
But speaking about paid packages.
My initial idea was to monetize SeoToolkit. The reason for it was quite simple, I would be creating this package in my own free time meaning that I wouldn't be able to spend as much of the time as I wanted on it. By making money from the package, I would therefore be able to set aside some time each week to work on SeoToolkit. However I also wanted to give back to the Umbraco community. I love open source and I love the way that everyone makes or helps with Umbraco packages. Making SeoToolkit open source and free could help other developers with creating websites instead of only focusing on people that would have the money to use my package.
In the end, I decided on the latter. I made my package open source and free to use, hoping that the community would also be able to help with the development of the package. While this did result in some contributions, I still have the issue that my time working on the package is limited, so any development on it is as well. It is hard to say if the package would have been more successful or would have failed if it was actually a paid package. Those are just things that you cannot really find out afterward.
I do still have an idea on how to monetize the package by creating paid extensions like SERP tracker or other more advanced SEO tools, but that is still something I am thinking about and haven't made a decision on.
Documentation is also something that I struggled with. How far do people expect the documentation to go? How far will they want to customize the experience of the package? These are all valid questions that need answering if you are creating your documentation.
I tried imagining myself as a developer installing my package to see what documentation would be most important. I could write any specific documentation at a later date if people actually needed it. This way, I wrote my documentation about "Setting up" & "How to use". Things like extending the code are important, but I feel like installing is probably the most important thing to write about.
And finding good documentation software is difficult too. I eventually settled on Gitbook, but I don't really have a good way to deal with the versioning of my software. In time, I'll have versions of SeoToolkit running on Umbraco 10, 11, 12. And they might not all be the same version, so I would need documentation that is specific to a certain version. While this is doable for a full-time job, I think this is a lot more difficult for someone writing packages in his own spare time.
After creating a package, I think it is always good to look back and see what might have gone wrong and how to fix that for any future package development.
I think the current package is great, but might be too focused on my own experiences. While I have created multiple websites in Umbraco, other people might be using a different way of creating websites in Umbraco. And the way that I created my package, I didn't really use anyone else's experience in the community.
While scary, I think it might have been good to ask people personally what they would like to see in an SEO package. Maybe there are features that I hadn't thought about and are quite crucial for other website developers.
Another point might be a planning thing. When working on a package, you try to include any feature that you can think about. Though, I think it is usually better to release earlier, maybe as a beta, than to try and make your package as good as possible. There will always be features to add or things to change, though you'll be able to better plan for that when you have feedback from the community.
If you don't release anything, then you also don't easily get feedback from the community about the features that you have created. Maybe nobody will use one of your modules, then it would be a waste of time to try and expand on it with newer functionalities. And this is also something that I experienced. I tried to add more and more modules to my package before I would want to release it. And now looking back, it might have been better to release with one module first. I would be able to gather data on if people were interested in a package like this. And if I would have seen that people aren't interested, then I could have taken the decision to stop developing it. By releasing it later, I am gambling on the fact that people would use it.
Finally, I would like to give people a way to start on their own packages. How do you start with something like this? I think the main thing you want to figure out is why you are doing this. Are you doing this for the community or just to help yourself out? Are you going to maintain it or not? Do you have the time to spend on supporting the package across the Umbraco versions?
While I am not trying to scare you away from creating packages, it sometimes might be a better choice to not publish it in the wide world. Or to at least let people know that you won't be maintaining it. That way, people will know what to expect.
But you can always give it a try and see how it goes. Maybe you will see that you are able to spend some time on it every week and actually maintain it. Or maybe you do it together with some other members of the community.
Another thing I would like to touch on is experience. While Umbraco experience is nice to have, don't force yourself to create something like Vendr or uSync. Start small, confirm that you are building something that has value for yourself or someone else, and keep on iterating on it. While Vendr and uSync are focused on certain parts of Umbraco, you might have more experience on another part.
So just get started, as I did. And see how far you can get. Use other open-source projects to gain experience on how certain aspects work. Want to know about Razor Class Libraries? See how uSync and SeoToolkit are doing it. Need some information about migrations? I am sure there are packages out there using it. And this way, you'll greatly improve your knowledge of Umbraco too.
I liked creating SeoToolkit and I think that it is a great package to use for clients. Being able to spend time developing new things is much more exciting than developing things we have to develop on every website.
There are things that I could have done better and I think that is important to keep in mind for any future package development.
I hope that this provides you with a glance into the world of package development and the choices that are being made. I hope this inspires you to either check out SeoToolkit or maybe even create your own package with the information that you've read here.
If you are currently building a package or would like to and would love some feedback on it, please send me a message on Twitter and I will get back you to.
And I hope you liked this blog post. I had an idea in mind, but I feel like this blog post now just touches on a lot of things that I wanted to talk about given my experience with SeoToolkit. So I hope you don't mind!
Thank you for reading this blog post!
