Showing posts with label Adobe Experience Manager. Show all posts
Showing posts with label Adobe Experience Manager. Show all posts

Saturday, June 1, 2024

AEM Edge Delivery Services — AEM Authored Content

 Most of you might have already heard about AEM Edge Delivery Services. Edge Delivery Services (EDS) is a set of composable services designed to enhance the capabilities of Adobe Experience Manager, along with expanded content authoring functionalities.

EDS significantly improves website performance, shortens development processes, democratizes authoring at scale, and enables real-time experimentation to drive better engagement. When you hear EDS, the first assumption might be authoring content through known tools like SharePoint and Google Docs. However, EDS also supports authoring content in AEM through the Universal Editor. By using EDS blocks, similar to how you would author content in Google Docs or SharePoint, EDS renders AEM authored content directly to the website.

In this post, let’s explore some details on authoring EDS-supported content in AEM.

As you all know, Edge Delivery Services (EDS) supports authoring content through SharePoint documents and Google Docs, and EDS renders this content on the website in a way that achieves high Core Web Vitals (CWV) scores.

Additionally, content for EDS can be authored through AEM. While the traditional Page Editor and Core Component-based content can be used, this requires an external converter to transform the traditional HTML into EDS-supported markup so that the EDS front end can render the content.

Another option is using the Universal Editor along with EDS blocks to author the content. This approach uses EDS blocks directly in AEM through the Universal Editor, eliminating the need for an additional converter setup. While the traditional Page Editor/Core Component-based approach is not recommended, it can be used as a starting point for completely migrating to an EDS-based approach. Start by rebuilding the front end with EDS, and later adapt the Universal Editor along with EDS blocks to author the content within AEM.

Some existing projects may have complex components, so a step-by-step approach works well — the migration is not mandatory for existing websites. They can continue to work with the traditional approach, but you should decide based on your primary focus and benefits. However, new projects can start by adopting EDS with the Universal Editor.

Document based and AEM Content through Universal
AEM Edge Delivery Services with Existing AEM Projects

Creating and editing EDS-based content directly in AEM through the Universal Editor brings additional benefits. EDS leverages AEM’s JCR repository to store content, ensuring secure storage. The Universal Editor can utilize most of the existing AEM authoring capabilities, such as MSM (with some current restrictions, like only page-level inheritance being supported, not block-level), translation, launch, workflow, and publishing/scheduled publishing. No code changes to AEM are required, as the code changes are directly synced to Edge Delivery Services from GitHub, avoiding the need to install and maintain a local AEM instance for development.

Let’s quickly explore the details of authoring content in AEM through the Universal Editor and EDS blocks, and how to render that content on a website using the EDS front-end approach.

The authors create and edit pages using EDS blocks defined in the GitHub repository through the Universal Editor. The content is persisted in the JCR repository. Scripts, styles, and other resources are applied from the Edge Delivery Service deployment. The code from the GitHub repository is synced to Edge Delivery Services. Additionally, the Universal Editor pulls scripts, styles, and other resources from GitHub to render the authoring view. A Publish Event Handler subscribes to publication events and calls the AEM Admin API to retrieve the content, which is then persisted to Edge Delivery Services. Requests for content from users are served from Edge Delivery Services through a CDN

Currently, EDS content authoring through the Universal Editor is supported only for AEM as a Cloud. In the future, it may be supported by AMS. The Universal Editor can be set up in a local AEM SDK, but it will have some restrictions, such as limited access to AEM assets from the local AEM system. To start with EDS content authoring through AEM, ensure that you have access to an AEM as a Cloud Sandbox or a real AEM as a Cloud environment. Also, ensure that the Universal Editor is enabled for your AEM as a Cloud program. If it is not enabled, reach out to Adobe support. The Universal Editor allows you to directly author content using EDS blocks inside AEM. The content is persisted in the AEM JCR repository and shared with EDS for rendering.

EDS Boilerplate for AEM Content:

The https://github.com/adobe-rnd/aem-boilerplate-xwalk GitHub repository provides a boilerplate template for EDG projects with AEM content. Create a project using this template to obtain the basic configurations, blocks, scripts, and styles, which can then be customized as needed. Additionally, configure https://github.com/apps/aem-code-sync to the new repository. AEM Code Sync listens to changes in your code repository and publishes the code to EDS.

Configure the AEM Author server details in the fstab.yaml file. Replace the default URL with the URL of your AEM as a Cloud Service authoring instance: https://<aem-author>/bin/franklin.delivery/<owner>/<repository>/main.

Additionally, change the mapping of the content paths in the paths.json file. For example, map /content/test to /content/aem-boilerplate/:/.

The files component-models.json, component-definition.json, and component-filters.json are used to manage and configure components:

component-models.json: This file defines the data models for components. It specifies the structure and properties that each component can have, detailing how data is represented and handled within the component.

component-definition.json: This file contains the definitions of the components. It includes metadata such as the component’s name, type, and other configurations that determine how the component behaves and interacts with other components within AEM. Additionally, it enables the mapping between EDS components and AEM component resource types.

component-filters.json: This file is used to define filters for components. Filters are used to manage the visibility and availability of components based on certain criteria. This can include conditions under which a component should be displayed or hidden, or how components should be filtered when queried.

Using component-models.json, component-definition.json, and component-filters.json, new components can be created and the behavior of existing components can be modified — Content Modeling for AEM authoring with Edge Delivery Services Projects | Adobe Experience Manager Creating Blocks Instrumented for use with the Universal Editor | Adobe Experience Manager. Additionally, scripts, styles, and other resources can be updated as needed.

The AEM Command Line Interface (CLI) can be used to develop and test the websites on a local system.

AEM Site Template for EDS Sites:

The AEM Site for EDS Sites template helps create new AEM sites through the EDS site template. The new site content can be created and edited through the Universal Editor and Blocks. Access the latest AEM Authoring with Edge Delivery Services site template from GitHub at https://github.com/adobe-rnd/aem-boilerplate-xwalk/releases

Authors can now create, edit, publish/unpublish and test pages in AEM through the Universal Editor for EDS websites. Styles, scripts, and other resources are managed in a GitHub repository, while the content is directly managed and persisted in AEM. The Universal Editor pulls scripts, styles, and other resources from GitHub for authoring. EDS syncs the code from the GitHub repository for the live website and fetches the content from the AEM JCR repository.

EDS blocks and Content mapped to franklin core components
The Franklin core components help map the EDS blocks and content to AEM. They also assist in instrumenting the pages and components for Universal Editor authoring.

Apart from content pages (e.g., index) and fragments (e.g., header and footer), different page types can be created, such as placeholders, spreadsheets, metadata, configurations, headers, and redirects.


The EDS website can be accessed through https://main--<repository-name>--<owner>.hlx.page or https://<branch>--<repo>--<owner>.hlx.live/. Custom website domains can also be mapped. Like the EDS documentation, there are no separate preview and live URLs; both display the same published content from AEM. The preview and approval to live should be part of the AEM Content Authoring workflow. The repository is mounted to a single AEM Author instance. The published EDS content on this instance is displayed on the live site, but you can adjust this by creating environment-specific branches and pointing those branches to the appropriate AEM Author instances.

Conclusion:

In summary, leveraging AEM Edge Delivery Services (EDS) for AEM authored content brings numerous benefits to your content management and delivery workflow. By utilizing the Universal Editor, authors can efficiently create and edit content directly within AEM, making use of advanced features like MSM, translation, workflow, and scheduled publishing. The integration with GitHub allows for seamless synchronization of scripts, styles, and other resources, ensuring a smooth authoring experience and consistent content delivery.

The EDS boilerplate and the configuration of key files such as fstab.yaml, paths.json, component-models.json, component-definition.json, and component-filters.json streamline the process of setting up and managing components. This setup not only enhances the flexibility and scalability of your AEM projects but also reduces the need for local AEM instances, simplifying development and deployment processes.

By adopting AEM Edge Delivery Services, organizations can ensure secure, efficient, and scalable content delivery, making it a powerful solution for modern content management needs.

References:

https://youtu.be/buR0IzGhryI

Getting Started — Developer Tutorial | Adobe Experience Manager

Developer Getting Started Guide for AEM Authoring with Edge Delivery Services | Adobe Experience Manager

Posted by at No comments:
Labels:

Thursday, May 30, 2024

Optimizing SEO Headers for Digital Assets — Adobe Experience Manager (AEM)

Search Engine Optimization (SEO) is crucial for ensuring that your digital content is easily discoverable by search engines and, consequently, your target audience. While much attention is often given to optimizing content pages, it’s equally important to focus on the SEO of digital assets such as images, videos, and documents. This is especially true for platforms like Adobe Experience Manager (AEM), where managing and delivering a vast range of digital assets is a core function. In this blog, we’ll explore the best practices for applying SEO headers to assets in AEM, focusing on the use of noindex and hreflang.

When it comes to digital assets, adding SEO headers such as noindex or hreflang can be more complex than for standard content pages. Unlike content pages, assets often serve a supporting role and may not need to be indexed by search engines. However, when they do, precise handling is required to ensure proper indexing and language targeting.

SEO Configurations for Content Pages:

For content pages, there are two primary methods to enable SEO configurations:

1. HTML Meta Tags:

SEO settings like noindex and hreflang can be added within the HTML metadata of content pages. This involves including these meta tags directly into the page’s HTML structure, either manually or using content authoring tools that automate their insertion.

2. HTTP Headers:

SEO directives such as noindex and hreflang can also be set at the server level using HTTP headers. This method provides an alternative to HTML meta tags for controlling SEO settings, allowing for centralized management of SEO configurations.

SEO Configurations for Assets:

For assets, the only viable method to implement SEO configurations is through HTTP headers, as assets do not have HTML structures where meta tags can be embedded:

1. HTTP Headers for Assets:

HTTP headers such as X-Robots-Tag for noindex and Link for hreflang can be used to manage SEO settings for digital assets like images, PDFs, and videos. These headers must be configured at the server or dispatcher level, ensuring that the appropriate SEO directives are applied to assets.

Example Syntax for Assets:

noindex:

The noindex directive tells search engines not to index a particular asset. This can be crucial for preventing duplicate content issues or for keeping non-essential assets out of search engine results.

X-Robots-Tag: noindex

Selective Application: Apply noindex to assets that do not provide direct value in search results, such as decorative images, icons, or internal documentation files.

hreflang:

The hreflang attribute is essential for assets that have multiple language versions. It helps search engines understand which version of an asset to serve based on the user's language preference.

Link: <https://example.com/assets/test-en.pdf>; rel="alternate"; hreflang="en", <https://example.com/assets/test-es.pdf>; rel="alternate"; hreflang="es"

Consistent Implementation: Ensure that hreflang tags are consistently applied across all versions of an asset.

Implementing SEO Headers for Assets in AEM:

Implementing these headers in AEM involves a combination of configuration and customization:

Dispatcher/CDN Configuration:

The Dispatcher/CDN configuration can be used to enable SEO headers based on specific patterns or directories. This configuration is usually done at the web server level (e.g., Apache) and is effective for broad, pattern-based rules.

Apache Configuration Examples

Folder Level Noindex Header:

<Directory /path/to/your/noindex-directory>
    Header set X-Robots-Tag "noindex"
</Directory>

File Level Noindex and Hreflang Headers:

<Files "/path/to/your/specific-file.html">
    Header set X-Robots-Tag "noindex"
    Header set Link "<http://example.com/specific-file-en.html>; rel=\"alternate\"; hreflang=\"en\",<http://example.com/specific-file-es.html>; rel=\"alternate\"; hreflang=\"es\""
</Files>

2. Custom Approach through Authoring

For more granular control, such as enabling SEO headers at the individual asset level, a custom approach is required. This involves using AEM’s metadata schema to allow authors to control SEO headers and implementing a custom Java filter to apply these headers to asset responses.

Step-by-Step Implementation

Step 1: Metadata Schema Customization

  1. Create or Edit Metadata Schema:
  • Navigate to Tools > Assets > Metadata Schemas in AEM.
  • Create a new schema or edit an existing one.
  • Add fields for noindex and hreflang. For example:
  • noindex: Checkbox
  • hreflang: Text field or multi-value field for multiple languages

2. Apply Metadata Schema:

  • Apply the schema to the relevant asset folders or types.

Step 2: Custom Java Filter

Create a custom Sling filter to read the metadata and set the appropriate headers.

1. Create a Sling Filter:

package com.example.aem.filters;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.engine.EngineConstants;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;

import javax.servlet.ServletException;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

@Component(service = Filter.class, property = {
    EngineConstants.SLING_FILTER_SCOPE + "=" + EngineConstants.FILTER_SCOPE_REQUEST,
    EngineConstants.SLING_FILTER_PATTERN + "=/content/dam/.*"
})
public class SEOHeadersFilter implements Filter {

  @Override
  public void doFilter(
      final ServletRequest request, final ServletResponse response, final FilterChain filterChain)
      throws IOException, ServletException {

    final SlingHttpServletRequest slingRequest = (SlingHttpServletRequest) request;
    final SlingHttpServletResponse slingResponse = (SlingHttpServletResponse) response;

    String metadataPath = slingRequest.getResource().getPath() + "/jcr:content/metadata";

    Resource resource = slingRequest.getResourceResolver().getResource(metadataPath);
    if (resource != null) {
      String noindex = resource.getValueMap().get("noindex", String.class);
      String[] hreflangArray = resource.getValueMap().get("hreflang", String[].class);

      if ("true".equals(noindex)) {
        slingResponse.setHeader("X-Robots-Tag", "noindex");
      }
      if (hreflangArray != null && hreflangArray.length > 0) {
        List<String> hreflangList = new ArrayList<>();
        for (String hreflangEntry : hreflangArray) {
          String[] parts = hreflangEntry.split(":", 2);
          if (parts.length == 2) {
            String lang = parts[0].trim();
            String url = parts[1].trim();
            String hreflangUrl = String.format("<%s>; rel=\"alternate\"; hreflang=\"%s\"", url, lang);
            hreflangList.add(hreflangUrl);
          }
        }
        if (!hreflangList.isEmpty()) {

          String hreflangHeader = String.join(", ", hreflangList);
          System.out.println("inside: " + hreflangHeader);
          slingResponse.setHeader("Link", hreflangHeader);
        }
      }
    }

    filterChain.doFilter(request, response);

  }

  @Override
  public void init(FilterConfig filterConfig) {
  }

  @Override
  public void destroy() {
  }

}

2. Deploy the Filter:

  • Deploy the custom filter bundle to your AEM instance.

3. Caching SEO headers on dispatcher:

To make SEO headers available to subsequent requests after caching, the headers need to be cached at the dispatcher. This involves adding X-Robots-Tag and Link headers to the cache headers in the Dispatcher farm file configurations.

/headers {
   "Cache-Control"
   "Content-Type"
   "Expires"
   "Last-Modified"
   "X-Content-Type-Options"
   "X-Robots-Tag"
   "Link"
}

Now the author can enable the required assets’ no-index or hreflang configurations.

[The AEM as a Cloud OOTB Fastly CDN blocks all custom headers set from AEM and allows only some standard headers. While the X-Robot-Tag header is currently supported, the Link header is not. Please contact Adobe through a support ticket to enable the Link header for your environments.]

Conclusion:

Optimizing SEO headers for assets in AEM is a nuanced process that differs significantly from optimizing content pages. By utilizing headers like noindex and hreflang, you can ensure that your digital assets are correctly indexed, served in appropriate languages, and managed efficiently.

Posted by at 1 comment:
Labels:
Subscribe to: Posts (Atom)