Best practices for removing sunsetted product pages from HubDB - timing and SEO considerations

Marketing & Content Hub Tips, Tricks & Best Practices
1

I’m looking for advice on the proper timing and approach for completely removing a sunsetted product page from our website.

Current situation:

  • We’ve sunsetted a product and replaced it with a newer offering
  • Already completed: Removed the product from our navigation menu
  • Already completed: Set up a 301 redirect from the old product URL to the replacement product page
  • The sunsetted product page still exists in our HubDB table

My question: When is the appropriate time to actually delete the product page from the HubDB table? Should I wait a certain period after implementing the redirect, or is there a best practice timeline for this?

Additional considerations I’m thinking about:

  • SEO implications and allowing search engines time to process the redirect
  • Any analytics I should review before removal
  • Whether there are reasons to keep the page data in HubDB even with the redirect in place

Has anyone dealt with a similar product sunset scenario? What timing worked well for you, and are there any pitfalls I should avoid?

Thanks in advance for any insights!

2

Hey @MNold21 - thanks so much for posting in the Community!
I’d like to tag in some experts to see if they have any context for us on best practices for this use case! @Josh, @Anton, and @Indra - any thoughts for @MNold21?
Shane, Senior Community Moderator

3

Hey @MNold21,

I’d say it depends on a few things:

  1. How long the product page was online
  2. Where it got shared(email, external pages…)

Regardless on those topics, I’d recommend to enable/create a redirect right after you sunset the page and leave it be. A 301 redirect (permanent redirect) is something that can exist indefinitely.

The only time you should think of removing the redirect is, when you’re about to create a redirect from the redirect - a so-called redirect-loop.

Example:

You’re sunsetting a page like domain.com/products/product-a. First you’re creating a redirect like domain.com/products/product-a → domain.com/products/new-product-a. But after a while you’re creating a new product page like domain.com/products/product-2026 and therefore creating a redirect like domain.com/products/new-product-a → domain.com/products/product-2026…

This means that somebody who might have bookmarked domain.com/products/product-a, would go through a (small) series of redirects domain.com/products/product-a → domain.com/products/new-product-a → domain.com/products/product-2026

While such redirect won’t give you a penalty right away, it can get quite messy after a while and you might end up in a redirect-madness.

If you have quite a few redirects in your redirects list, you can export it as a CSV and work in your favorite CSV tool (Excel, Apple Numbers, Google Sheets) to untangle such redirect-loops.

If you’re using something like SEMRush - it can show you such redirect loops much easier and save you time looking for them.

As for the crawling time:

There’s no guaranteed timeline the Google Crawler comes back to your page. If you have a page that’s frequently changing it might crawl your page several times a day, but also can crawl your page just every other month if it’s more on the static side of things.

A good addition to your tech-stack is Google Search Console, if you’re not already using it.

With it you can manually trigger a recrawl of your whole page. Jsut add domain.com/sitemap.xml to it.

As for keeping the data in HubDB or not:

It fully depends on what you’re planning and how big your HubDB is.

If you’re not planning to enable the product ever again, you can delete it from the HubDB, but I’d recommend to export the HubDB before removing it, so you’ll have a backup.

It might be also benefitial to delete it if you need the row as a single HubDB table is limited to 10k rows.

A tip I can recommend is to add a column with a boolean like “page published” to the table and wrap the whole product page template in it. This will give you the ability to easily trigger the page to be live or not. If you do something like this, you will still need to create redirects manually, but it might be easier to handle/filter live pages in the table itself

best,

Anton