Once you’ve defined your vision for relaunching your website and aligned business goals with stakeholders, the real planning begins. You need to determine which content from your existing site is most valuable to engaging users and map out a plan to move all of this content over to the new website. A comprehensive content audit is needed to make sure you understand all of your existing content. When evaluating your content architecture, you must consider factors such as how much content exists on your old site (more content may impact factors like performance, crawl time and SEO) and how this content is organized both in terms of navigation and within your site’s taxonomy. When performing this content analysis, you want to focus on ways to improve overall site functionality as well as make it as simple as possible for different users to get the information they need.
Creating a Component-Based Content Strategy
As part of upgrading the Acquia website from Drupal 8 to Drupal 9, we revamped our content model in Drupal to embrace a component-based architecture. A component-based development approach involves creating reusable components in Drupal that can be reapplied across different layouts and displays. Rather than build an entirely new site from custom code, using a low code site builder with component-based design features empowers both marketers and developers to work on the front end, speeding up development timelines.
Part of Acquia’s site evolution was embracing our own low-code tools in order to give our marketing team more control in shaping the site experience. Site Studio’s content modeling framework allows teams to define a specific content architecture that could then be used to create components. Site Studio leverages a powerful set of visual UIs within Drupal to create a component-based design system or pattern library that can serve as a master style guide across multiple pages and websites.
The most important consideration when mapping out our new content strategy was defining what components and content types needed to be migrated to the new site and which content could be consolidated and simplified. The freedom that Drupal offers can often be a double-edged sword if teams set off on creating too many custom content types that need to be reconstructed again and again. For example, changing a few features on a case study template or adding a field to a form can cause extra complexity when recreating these elements on new pages. To stay organized and expedite the site migration and development process, we needed to first define how we used structured and unstructured content types in Drupal.
Content Modeling: Structured vs. Unstructured Content in Drupal
Unlike many other CMS options, Drupal supports both unstructured and structured content types. Traditional content management systems only allow users to create designs for individual pages, making it difficult and time consuming to recreate content across multiple interfaces and various sites.
Drupal can break down entire web pages into smaller entities that can be used to compose content. If you have separate content types with identical fields for e-books, white papers and infographics, you can instead create them as one content type and create a drop-down menu or select list to indicate each specific asset. This way, your developers only need to target the select field on one content type during the migration. Once you’ve defined your chosen content types and fields, each entity can be made to reference other entities across the rest of the site. When mapping out our content migration, our team worked to consolidate 21 existing structured content types down to just 12 content types that would serve defined functions across the site. Having a structured template for content makes the layout process simpler than having to manage a bunch of content types with minor variations and permutations in formatting.
Managing unstructured content in Drupal such as undefined image and text fields can be a little more complicated. When migrating unstructured content and media entities across the site and building new unstructured content pages such as our new homepage and product page, we used Acquia Site Studio to create a master library of components, so we could customize all of these different page types quickly. By building out templates and leveraging Site Studio’s drag-and-drop interface, our team could more easily distribute the work to launch new sites and pages in real time without needing to write any new code. With our web team able to quickly spin up various components and templates, we could spend less time on maintenance and more time investing in how to optimize the total website experience to reflect the needs of the customer.
In our next Website Relaunch Survival Guide post, we’ll look at the content migration and testing process in Drupal 9.