2. 3. 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 CMS/EMS
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 Kentico CMS/EMS
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 Kentico Cloud, 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 Kentico Cloud 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 CMS/EMS
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 created in parallel with implementation
A client had only 2 months to launch a new web site with 300 pages of content. Since the development was projected to consume at least 1 month, they knew they wouldn't have enough time to create content after the development work is done.
Therefore they decided to use Kentico Cloud to start content production in parallel with the development. This approach allowed them to finish the project on time.
Content migrated to Kentico
A partner was migrating a client's web site from an existing CMS. Since the CMS had most of the content stored in a structured fashion, they decided to import the content using the Kentico API.
As they completed the data structures for each type of content, they created a simple one-time import tool to map the content from the old CMS to the Kentico data structures. They considered the Kentico import toolkit, but since some data had complex relationships, they decided it would be easier to build custom import tools.
Content not ready until after implementation
A client had 6 months to launch a new web site. The partner estimated that the development phase would take 3 months. As content would not be ready until then anyway, the client decided to enter the content directly into the CMS in a staging environment.
Product content managed outside of Kentico
A client wanted to use Kentico's built-in e-commerce functionality, but their products were managed in an external ERP system. Since product information needs to be stored in Kentico in order to use the built-in e-commerce features, they determined that they would synchronize Kentico with the ERP system on a nightly basis.
To accomplish this, the partner built a custom scheduled task, which synchronized only the minimum of data that was necessary to make the e-commerce features work. When displaying product information, they connected to the ERP live to get data not available in Kentico.
Content tree or sitemap
Content organization, URLs and SEO
- Organize your content tree structure to achieve the URLs you want from the start rather than modify the default URLs later.
- This is also used to generate the structure of the XML sitemap for search engines.
- Modify the URL of page or add aliases only as needed.
- Utilize 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 to cover a very specific scenario to reference another object of a specific object type (e.g., assign a country (built-in object) to an office page).
- Use advanced content modeling when you need to enable editors to build more complex content using other content (primarily used for MVC development model).
- Define which pages or page content needs to be presented on multiple websites or reused in multiple places on the same web site:
Consider linked pages when sharing whole pages.
Consider using viewer web parts or the API when sharing only the content of a page (e.g., home page slider content or the latest 5 news items).
- 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:
- 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 Kentico 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 feature in order to prevent unintended overwriting of content changes.
- Consider the following to keep outdated content under control:
- 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 to automate the translation process (this can be part of an advanced workflow).
- Use 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 best practices article for more details).
- Keep the number of pages reasonable as the content tree storage is not suitable for large amount of content items.
- 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.
- 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).