Configuring Web Spotlight in Kontent for any scenario

But there are many ways to implement navigation, taxonomy, URL structures, and content hierarchy in a website. Often what gets implemented in a website is the result of lengthy user research, information architecture design, visual design and custom development, in order to produce a highly optimised and effective website. In a traditional CMS, this implementation is done inside the CMS platform, which ultimately serves webpages to users. But a headless CMS is completely separate; the website is built independently of it. So how can we make sure the 'content tree' in Web Spotlight is familiar and useful for content editors?

The 'content tree' for our own website is set up in Web Spotlight to perfectly match our on-site navigation

Different websites, different requirements

The issue is even more complex because different types of websites tend toward different content structures and navigation types. 

A website with a huge amount of technical information such as Cancer Council Australia needs a highly organised, multi-level content hierarchy and a navigation that allows users to dig deep and find the information they're looking for. Accordingly, Web Spotlight's content tree would be best used to help a content editor quickly find content they are looking to edit within a huge content library, rather than strictly representing the main navigation on the website.

More marketing-focused websites (such as this one!) tend toward a flatter structure, with short, SEO-optimised 'vanity' URLs, and often a 'megamenu' which surfaces key pages or calls to action in an effort to 'convert' visitors toward particular goals. In this case, content editors and marketers are more likely to want to use Web Spotlight to manage and optimise that marketing-focused megamenu in a visual way.

The basics

Don't miss this step!

Before you go launching into solving all of your complex information architecture problems with Web Spotlight, there are a few steps and concepts that are common to all setups.

1. You need to enable it first! If it's part of your subscription, you'll find a big button in your Project Settings to enable Web Spotlight. This activates the User Interface for Web Spotlight, but it also creates some special Content Types for you to start: Homepage and Page.
2. Use the Homepage item (rename it if you like) to teach Web Spotlight where your content tree 'starts'.
3. Use the special Subpages element in your content models to build your tree.

Five different ways to configure Web Spotlight

Web Spotlight provides a range of options for modelling your 'content tree', which I've broken down into five broad examples. But there are as many as your imagination allows!

1. Pages + structured content

Use Web Spotlight to add Page functionality to your content.

• Use the out of the box Web Spotlight types (Homepage and Page) to build your tree.
• Page URL (slug) and preview URLs are attached to the Page type.
• Content is structured into a library of reusable items, and completely detached from the concept of the website and page URLs.
• Pros:
  • This could be the easiest way to add Web Spotlight to an existing project full of nicely structured omni-channel content.
  • This approach is very omni-channel friendly - all web properties are abstracted out into the Page type, rather than tied to your content.
  • This is what you get when you just 'turn it on'.
• Cons:
  • Adding a new Page will always require adding linked items too, with their own workflow.
  • Conversely, adding a new item in your Content Inventory will require you to also add a corresponding Page in Web Spotlight (if you want it to be a page on your website).
  • By only using one content type to represent pages, you’re limited to only one Preview URL configuration.

2. Pages all the way

Use Web Spotlight to model your entire website.

• Extend the Page type to contain all of your content too (rich text, custom fields, linked items, whatever you like).
• Create/clone more types to also act as other pages/templates if you like.
• Configure your Homepage type to allow these new pages within its Subpages element.
• Pros:
  • For simple web-only projects, this could be a winner.
  • All content related to a page is in a single item, which simplifies workflow and editor experience.
  • It’s easy to add new content directly from within Web Spotlight.
• Cons:
  • It’s not easy to share or reuse content, or link to it in multiple places in your navigation (or multiple navs, for example a page in your header and footer).

3. Separate navigation + pages as content

Use Web Spotlight to model your website navigation.

• You could use the out of the box Page type, or your own.
• Use the subpages element to build a recursive navigation tree.
• (Optionally) reference a nested Page type which contains page metadata and Preview URL configuration.
• Pros:
  • Manage all content related to the page in one item and one workflow (page content, metadata, URLs, sharing info etc).
  • A single type used in Web Spotlight, but can still have many different preview URL patterns configured for different types of content.
  • Allows marketers to visually build any navigation structure (for example, a megamenu).
  • You can link the same page in multiple places in your navigation without duplicating it.
  • Can easily have pages hidden from navigation, or navigation that doesn’t even point to an actual page.
• Cons:
  • Adding a page generally means two steps for marketers: add the page, and add it to the menu.
  • Set-up of nested preview configuration requires exact naming of one element.

4. Completely separate

Web Spotlight used only to improve the editor experience, but not to model the actual website content.

Web Spotlight doesn't have to model your entire website

• Homepage and Page content types can still be used to build out a handy list of pages for editors to view and edit, but it is essentially a list of bookmarks/shortcuts.
• Simply link the pages you need to edit into Web Spotlight and arrange/reorder as you see fit, without being concerned that the website will be affected.
• Very handy for hybrid sites that integrate with multiple data sources, and only require Web Spotlight for specific areas such as landing pages.
• Pros:
  • Highly optimised for a marketing user’s experience.
  • No special implementation required in the presentation website/app except the Smart Link SDK.
• Cons:
  • You miss out on the cool ability to actually organise your site’s hierarchical structure using Web Spotlight.
  • The manual nature of it means it can be easy for pages to 'go missing' from the list.

5. Multi-site or even multi-channel

You're not limited to a Homepage -> Page model either. Why not adapt it for multiple home pages for different sites? Or a homepage and a mobile app?

All of the above

This is not a list of present configurations - they're just examples of what's possible. There's nothing stopping you modelling multiple channels, each in their own way - your website's megamenu, some landing pages on a microsite, and a full hierarchical catalogue of documentation pages for a mobile app, all in one place.

Total flexibility

Of course the pro for ANY of these methods is that it's supported by Web Spotlight! This is definitely the best part - you don't have to change the way you model your content or choose to implement your website in order for it to 'work' in Web Spotlight. You just configure Web Spotlight to match the way your website works, or the way your content editors work, which is how it should be. This means if you've already built your site and you want to add Web Spotlight later, chances are it's going to work just fine.

Could this actually be an improvement on the original?

Myth: a Headless CMS limits your ability to manage content in a visual hierarchy. 

Sure, some of them do, but not Kontent with Web Spotlight.

In most traditional CMS platforms, the content tree strictly represents the way content is structured in the website.

Web Spotlight demonstrates a significant reversal on the idea that Headless CMS limits your ability to manage content in a visual hierarchy. Its flexibility potentially makes the content tree more intuitive and helpful for content editors than what you see in many traditional CMS platforms... if configured correctly. 😉