2.2. Planning content management
Every organization has a different process for managing content. Some projects have strict legal requirements whereas others may have a minimal set of suggested guidelines for editors. You need to understand and plan for these requirements up front. By supporting the business processes of the client, you are setting them up for continued success. In this section we explore the key facets to creating a solid content management strategy.
Content is created and managed inside Kentico Xperience
If content is managed this way, the developers must prepare the data structures and storage before content can be entered. If the project is already live, we recommend using a staging environment for content creation rather than directly editing in the production.
Content is created outside and managed inside of Xperience
When content is managed in this fashion, the content can be created before or parallel to the development. One example of such a system is Kontent, which enables content editors to create content in advance before the site is ready for them, while enabling developers to easily import this content to Kentico EMS via Kontent API.
Another example would be if all content was created in spreadsheets or in some other system with data structures that can be mapped and imported using the Kentico API or via the import toolkit.
Content is created and managed outside of Kentico Xperience
This content is typically used for items like a product catalog, and is either synchronized to Kentico using scheduled tasks, the Integration bus, or pulled directly from the external system at runtime (e.g., web services, SDKs, etc.).
Content tree or sitemap
Content organization, URLs and SEO
- The organization of the content tree can be used to generate the structure of the XML sitemap for search engines.
- When using the portal engine:
- Modify the URL of page or add aliases only as needed.
- Utilize wildcard URLs to use a single template for displaying dynamic content from various sources (e.g., custom tables, custom module classes) while still having SEO friendly URLs.
- Organize pages in the content tree if you only need simple categorization, where a page belongs to only one category.
- Use one of the following options for more complex categorization:
- Use page relationships when you need to manually create relationship between different pages (e.g., related news stories).
- Use tags when you need a flat, non-hierarchical structure that allows for classifying pages based on various criteria (e.g., topics).
- Use categories when you need to have a hierarchical structure to page classification (e.g., an iPhone page could be assigned with the cell phone, cell phone > smart phone, and apple categories).
- Use field references when you need reference another object of a specific object type (e.g., assign a country (built-in object) to an office page).
- Define which pages or page content needs to be presented on multiple websites or reused in multiple places on the same web site:
- Restrict access to individual pages or content tree sections with page permissions:
- Grant permissions per user or role (memberships can be assigned with roles and gain permissions indirectly this way).
- Check permissions only when necessary as it is performance intensive.
- Decide which of the following system pages need to be in the tree and editable by content editors:
- Search result page
- Logon page
- 404 Page Not Found (critical for SEO)
- Robots.txt (critical for SEO)
- Sitemap (critical for SEO)
- Define a content life-cycle and list all necessary steps.
- Apply different workflows to different sections or pages if necessary.
- Specify authorized roles or users to modify, approve, or reject the page in each step as well as to be notified about these changes.
- Consider restricting the number of page versions in the settings since all content under workflow is automatically versioned.
- Consider enabling the content locking feature in order to prevent unintended overwriting of content changes.
- Consider the following to keep outdated content under control:
- Hide pages from live site by archiving or unpublishing them.
- Move pages to a dedicated archive location in the content tree.
- Identify how often content should be reviewed.
- Control data growth and keep desired performance by having processes in place to:
- Delete old pages (with replacement URL redirection for SEO purposes).
- Move old pages out of the content tree (e.g., to a custom table or custom module class).
- Consider automating content processing with advanced workflow.
- Use translation services to automate the translation process (this can be part of an advanced workflow).
- Use culture specific URLs (e.g. /en-us/news and /fr-fr/news) for the same page to meet your SEO requirements.
- Consider whether a page should fall back to the default content, 404, or other page if it is not available in the current language.
- Evaluate whether you should use SKUs with pages versus the standalone SKUs option of storing products (see the E-commerce customization model documentation for more details).
- Keep the total pages for all sites, including culture variants, under 500K pages.
- Keep the number of direct children of any particular page under 1K.
- Keep content categorized, grouped, or structured using some rule (e.g., group content by release date: /Blogs/2016/January/My-Blog-Post).
- Move content outside of the content tree after publishing if you expect there will be too much content.
- This allows you to use workflows while keeping the content tree size small.
- Restrict access to applications, modules, and WYSIWYG toolbar options based on roles.
- Restrict editor access to certain page properties (e.g., metadata, URL alias, etc.) within the Pages application as necessary.
- Restrict editor access to certain buttons (e.g., source view, font color, etc.) as necessary.
Determine the proper way to store media files on the website by analyzing the nature of the files (e.g., sizes, types, quantity), as well as how they will be used (e.g., do they need security, resizing, or watermarking).
We recommend storing most files in the standard media library which stores the files on the disk by default. Furthermore, this approach also provides the easiest path to using a CDN. We recommend avoiding serving files from attachments or the content tree unless you need functionality that can only be provided this way.
- Use the CMS.File page type for storing files in the content tree when you need features like workflow, multilingual support, search, permissioning, and categorization (tags or categories).
- Avoid using the content tree if you plan to upload a large quantity of files or large size files as this can severely impact the performance.
- Use only when you need to associate file(s) with a specific page.
- Attachments follow the life cycle and restrictions of the page they are attached to.
- Use when you are storing a large number of files or storing large files.
- Use when you need to serve the files from a CDN.
- Create a custom smart search indexer if you need to search in a media library, as the binary data of media library files is not searchable by default.
- Avoid media libraries if you need to secure the files, as the files are always accessible (Note: you can restrict access to a media library in the administration interface, but the files are still public).
- Store your design assets on the file system in an organized way (e.g., images for a stylesheet should be stored in the App_Themes subfolder for the stylesheet they are related to).