The first Women in Tech SEO website was a Gatsby + Contentful project built in a weekend to showcase meetup events the community had. Over the years, the community grew with different initiatives like speakers hub, founders hub and knwoledge hub. The launch of their 3 conferences needed more work on the website to be able to market them.
We started the website from a template that served us well but with growing needs for customisabilty, uniformity and ease of use we decided to overhaul the website.
The new website is built from scratch to suit what we needed. It’s powered by Astro with the content managed by Sanity. This might sound like just another iteration but it isn’t. We overhauled how content is structured with the aim of allowing the WTS team to create interactive pages without any development work required.
The old content structure
The old content structure was tightly tied to the content it was representing. This might seem like a good thing, and in some cases it is, but it actually meant that any new content types required a developer to integrate the new types. It also made content types not reusable which became painful to manage with every new page layout being added.
For example, we had a “Blog page” type that was only used to render blog posts then WTSPodcast happened and we needed a new type to render the podcast page.
This is not a limitation for using Contentful but rather a limitation with how we did things initially. Overhauling the content structure gave us time to rethink the tools we were using.
The new content structure
We had two options in the rebuild. Either stick with the same content structure or think of a new way to model it and we decided to find a better way.
Most marketing websites end up having a few templates that get reused everywhere and that was the case for WTS. The old content structure worked great and was easy to reason with but it failed when a new template or page was needed. So what if we tried to get the best of both worlds?
The new content structure breaks down all the existing content models into smaller pieces called “visual blocks”. Templates became a collection of visual blocks. For example the Blog page got broken down to:
- title
- body
- author
This new structure gives us the flexibility of creating new templates by grouping a few visual blocks, and the uniformity of sharing these templates with all content editors to use. It also has the downside of making the content editing experience a bit more complex compared to the old structure. It takes extra steps to find the right block to edit or update but that’s a compromise we were willing to make to gain more flexibility.
Picking up the right tools
I loved using Gatsby pre V4. It was simple enough to pull some content and statically render your website. I didn’t have to mess with a lot of config to get things up and running. Then Gatsby just died.
Astro, for me, is the best framework right now for marketing websites – and more. Very easy to setup, well documented, well supported and you aren’t tied to any frameworks. Having used React with Gatsby I knew that using React is overkill here. All we needed is plain old HTML, CSS and some JS here and there. We still do use React in some places but the rest is just vanilla. This is the beauty of Astro: it works with or without a framework.
Picking Astro was a no-brainer but picking a content management system was a bit more involved. We wanted something customizable and flexible, with a good content structure management, a generous free tier, and a performant API. Sanity hit all these criteria for us.
The content structure lives near the code in schema files which makes development of the visual blocks easier. It has an editor called Sanity Studio that is very customizable and flexible. The studio supported our concept of templates and draft previews with minimal configuration. All these factors made Sanity a great fit for the WTS new website.
Planning our work
Any software-related product doesn’t live in a vacuum. It has dependencies and consumers, and if you aren’t building with this in mind then you’re bound to start a rebuild. This was exactly the situation we found ourselves in when the WTS website evolved.
A good starting point is finding out what content we needed to consume. We broke down the old website into templates, which gave us insight into what we should support. Each template got broken down into visual blocks. Finally, we dug into what was needed for the near future and documented it.
The brilliant designer we worked with helped us complete the picture. She polished our portfolio of visual blocks so that we knew the requirements and variations of each block.
Having all this work sketched out and planned meant that we also documented the new editing experience before we started development – which was a big win.
Thoughts on the schema
Sanity allows you to specify your content models through JSON, and Sanity Studio takes care of displaying the forms and input fields required to fulfill your schema. That means you have two different types of users interacting with these models. From a developer’s point of view, you trust your schema to have certain fields and structure your code accordingly. From a content editor’s point of view, if something is optional, then filling in some fields can be skipped or done later. Each Sanity field comes with validation tools like required(), which help the Studio enforce content integrity.
We also relied on custom previews to make editing content as smooth as possible. Instead of opening Sanity Studio and seeing hard-to-read JSON, the preview now uses values from the content and displays the type of the visual block.
Enhancing the Sanity Studio Experience
To streamline the content editing workflow, we introduced a few key improvements in Sanity Studio:
-
Default Values: By setting sensible default values for many fields, we reduced the friction for content editors. This means that common or repetitive data is pre-populated, allowing editors to focus on what’s unique about each piece of content.
-
Dropdowns to Limit Scope: Implementing dropdowns for fields with a limited set of acceptable values not only enforces consistency but also simplifies the selection process. This constrained input reduces the chance for errors and helps maintain a clean, predictable data model.
-
Conditional Field Visibility: We took advantage of Sanity’s ability to hide fields that aren’t relevant in a given context. By conditionally displaying fields only when needed, the Studio interface becomes less cluttered and more intuitive for editors.
Another important design decision was determining what should be a document versus an object. In our experience, not everything warrants the overhead of being a separate document. Documents are best reserved for content that is shared across multiple sections of your website or needs to be accessed independently. Conversely, objects are ideal for grouping related fields that only make sense within the context of a parent document. This distinction not only keeps our schema lean but also simplifies both content management and query performance.
Query optimisations
Optimising your data queries is crucial for a fast and responsive website. Here are some of the strategies we adopted:
-
Plan Your Queries: Before crafting your GROQ queries, take a moment to plan exactly what data is needed. Limit the number of queries by fetching only the required fields. Leverage GROQ’s spread operator to fetch nested fields efficiently, and resolve references only when necessary. This ensures that your queries are both efficient and scalable.
-
Abstract Client Access for Previews: To support dynamic content previews (for instance, draft versus published content), abstract your access to the Sanity client. By passing a “perspective” or context to the client, you can seamlessly switch between preview modes. This abstraction layer simplifies your codebase and makes it easier to manage content revisions.
-
Unified Layout with Reusable Blocks: Our approach was to maintain a single, consistent layout for the site while off-loading the dynamic parts of the content to visual blocks. This not only simplifies layout management but also promotes reusability and consistency across various pages.
SEO considerations
A solid SEO strategy is key for any marketing website. Our implementation included several best practices:
-
Self-Referring Canonicals: Each page includes a self-referencing canonical tag to clearly communicate to search engines which URL is the primary version. This helps prevent duplicate content issues and consolidates ranking signals.
-
Robust Internal Linking: We ensured that internal linking is enforced through Sanity’s rules and schema design. For example, when dealing with paginated listing pages, we use references to create robust internal links between related pages. This structured linking not only aids in navigation but also signals content relationships to search engines.
-
Comprehensive Open Graph Schema: Every page is equipped with an Open Graph schema, ensuring that when your content is shared on social media, it displays attractively with a clear title, description, and image. This attention to social metadata increases engagement and helps control the narrative around your content.
The video version of this blog post was delivered in a Sanity community meetup in London. You can find the fill video here.