Skip to main content

Legacy File-based Redirects Deprecation Notice

What is changing

We will be discontinuing support for the legacy file-based redirects (you may have onboarded with in the past).

After December 7, 2026, redirects will no longer be supported from files; likely resulting in 404 errors when the content is requested. Based on the type of redirect a migration path(s) is shown for how you can keep them using the supported redirect framework.

Is my organization impacted?

Your TAM will be reaching out with your redirects with their classification (type of redirect) that you can follow rest of this deprecation guide to plan your migration until December 7, 2026.

Types of legacy redirects affected

The legacy File based re-directs will no longer be supported. In reviewing the legacy redirects fall into three categories:

  1. Single URL redirects

    • These were likely created when you on-boarded to Arc XP to map previous CMS URLs to re-pathed Arc website URLs

  2. Wildcard redirects

    • Redirects designed to match multiple URLs and route them to a single target or patterned destination

    • Redirects using arcio; which has been deprecated previously.

  3. Custom rewrites for specific output types

    • Rewrites used to serve robots.txt, ads.txt, or app-ads.txt with a text outputType=text for PageBuilder

Action required

If you would like these redirects or rewrites to continue functioning after the deprecation date, you must migrate them to the currently supported redirect configuration.

We recommend the following steps:

  1. Review the list of legacy redirects we provide.

  2. Determine which redirects must remain active.

    • Are you seeing traffic to this URL in your Google Analytics data?

  3. Recreate or migrate those redirects using the supported Redirect UI / Redirects API and current configuration standards, or leverage Draft API to link these redirects to the existing story.

Table 6. Types of Redirects

Migration Path

Redirect UI / API

PageBuilder Custom Content Source

Draft API

Single

YES

YES

YES

Wildcard

YES

YES

NO

outputType=text

N/A

N/A

N/A

Custom outputType

YES

NO

NO

arcio redirects

YES

NO

NO



Migration Paths

  1. Redirect UI / API - You can chose to implement these in edge redirects, remember there is a 1k limit on these redirects.

    1. Redirect UI: You can chose to implement these in edge redirects UI, remember there is a 1000 limit on these redirects Configuring URL redirects

    2. Redirect API: You could programatically load the edge redirects. Redirects API

  2. PageBuilder Custom Content Types - Through PageBuilder you have control over your custom content types. What are the different kinds of redirects in Arc XP? Use Outbound feeds Managing .txt files with Outbound Feeds

  3. Draft API: You can Use Draft API to either link these redirects to an existing story or keep the redirect as a standalone object (best for 3rd party or off-domain redirects). Creation of redirects in Draft will also require evaluation of pagebuilder resolvers and templates to ensure the original URL’s are matched there, which should be part of the your evaluation of whether to utilize edge redirect capacity. How To Create Story Document URL Redirects Using Draft API

Warning

If no action is taken before the deprecation date above, the listed legacy redirects will stop functioning; resulting in 404 Errors.

Tips & Tricks

Tips for Migrating Legacy Redirect URL’s

Here are some tips to help you migrate the URL redirects you wish to retainSingle URL redirects

These redirects are straight forward single URL to single URL

Examples

  • rewrite ^/collection/expert-picks-2019/$ /football/expert-picks/? permanent;

  • rewrite ^/vida-y-estilo/$ /espanol/al-dia/vida-y-estilo/? permanent;

  • rewrite (?i)^/amp/votre-ville/ville/moto/$ /amp/info-paris/? permanent;

Wildcard redirects

These redirects appear in several different forms.

  • rewrite ^/amp/(.*)$ /$1?outputType=amp? permanent;

  • rewrite ^(.)/WebGraphics/(.)$ https://www3.examplemediaco.com/$1/WebGraphics/$2?arc404=true permanent;

  • if ($request_uri ~ "^.amp.html$") {rewrite ^(.)amp.html$ $1story.html?outputType=amp?  permanent; }

Wildcards can be recognized by the use of regex wildcards such as .* or character classes (foo|bar|apple|orange) and can also exist in more complex if statements. In both cases capture groups can be utilized to modify the redirected URL output. All of these rules can be re-implemented via the redirects UI/API Configuring URL redirects, Redirects API

Redirects using /arcio/

While redirects via /arcio has been deprecated for several years we wanted to give you one last look at what is out there that is currently receiving a 404 error when request in case you wanted to deliver a different experience using the redirect UI or API. If you do nothing, they will continue to receive a 404 error when requested.

/arcio/ redirects are a special sub-set of the wildcard redirects and are documented Outbound Feeds Requesting OBF Redirects, since these standard redirects were based on real world requests that were implemented in fragment files these will usually be a 1:1 replacement. Example:

rewrite (?i)^/arcio/ans/(.*)$ / permanent;

There will be redirects that match outside of the pre-defined set of paths however, things that were implemented prior to the standardization, such as

if ($request_uri ~ ^/arcio/news-sitemap/\?from=200$) { rewrite ^.*$ /arcio/news-sitemap/google/?from=0? permanent; }

Rewrites based on outputType

These rewrites were standardized early on as tickets for customers to submit to ACS, the runbook for these instructed specific lines to be added to the redirect fragments for the customer. These redirects were later productized into feature flags in web-delivery which accomplish these same redirects with standard rules. It is possible that these rules were customized by ACS, ether at customer direction or while attempting to be helpful, but going forward customers will need to migrate to the supported rules

outputType=text? last;

Note

Good News - You do not need to do anything for these. Arc will automatically configure your rewrites for ads.txt, robots.txt and app-ads.txt. This information is information in nature only.

Examples

  • rewrite (?i)^/ads.txt$ /ads.txt?outputType=text? last;

  • rewrite (?i)^/robots.txt$ /robots.txt?outputType=text? last;

  • rewrite ^/app-ads.txt$ /arc/outboundfeeds/app-ads.txt?outputType=text? last;

After they are migrated, this is how you can see them:

  • How can I view the feature flags for each site?

  • How can my engineers use the feature flags in OBF?

    • Managing .txt files with Outbound Feeds outlines how the flags are supposed to work. There are two options for the feature flag. You can either configure these URL’s to

      1. be handled via OBF (as documented) or

      2. they can request that “fusion” which is their default pagebuilder bundle render it or

Custom outputType= last;

If you have rewrites that include rules which map to custom outputType’s for specific url’s or similar you will need to migrate to use the default outputType, or have all URL links to the pages contain the desired outputType for the page in question. Here are some examples:

  • rewrite (?i)^/foo/$ /foo/?outputType=account? last;

  • rewrite (?i)^(.*/)amp.html$ $1?outputType=amp? last;

  • rewrite ^/gsync.html$ /gsync.html/?outputType=static? last;

To maintain your customer output type you will need to update the default output type on the resolver and make sure that the matching pattern for the targeted resolver aligns with the matching pattern in the rewrite statement. Here is how you do that

How can I view the feature flags for each site?

Viewing active site details outlines how you can view the feature flags for each site.

How can my engineers use the feature flags in OBF?

Managing .txt files with Outbound Feeds outlines how the flags are supposed to work. There are two options for the feature flag. You can either configure these URL’s to

  1. be handled via OBF (as documented) or

  2. they can request that “fusion” which is their default pagebuilder bundle render it or

How to read the rules

URL Matching

URL matching with query params uses an if ( style. however, you may see this style to include matching on URL’s which don’t need query parameters.

rewrite (?i)^/boyslatin/$ /news/philadelphia/a/boys-latin-high-school-football-philadelphia-20181226.html? permanent;

vs

if ($request_uri ~ ^/philly/forums/eagles/?page=1&sortBy=(.)$) {rewrite ^.$ /eagles/? permanent; }

Case-insensitive

(?i) means case-insensitive matching, it’s not consistently used but should be evaluated for how pagebuilder resolver or edge redirect matching works when creating new rules

Support

Our team is available to assist you with reviewing your list and planning your migration. Please contact your Technical Account Manager if you would like guidance or have questions about how to transition your redirects.

We appreciate your prompt attention to this update and your continued partnership.

In this section: