Best way to update URL alias for deleted node

Events happening in the community are now at Drupal community events on www.drupal.org.
el_reverend's picture

Hi all,

what would be the best way to pragmatically update the URL alias for a deleted node? When I delete a product, the URL alias stays intact, which of course then get handled by Drupal and returns a 404 (in my case I have an additional search provided). I ...

I would like however to redirect the URL to the products overview page as a permanent redirect (301) for that node. While this can be dome manually (in Drupal minus the 301) in various ways, does a module exist for this already or how would I best go about this?

Another questions is of course, now that the URL redirects to an existing page how does something like this impact overall SEO? Any impact at all, or little?

Thanks for your expertise in advance.

Comments

When I delete a product, the

christefano's picture

When I delete a product, the URL alias stays intact, which of course then get handled by Drupal and returns a 404 (in my case I have an additional search provided).

This sounds like a bug. The path alias should be unset when deleting the node. Can you describe what moving parts are involved here?

I would like however to redirect the URL to the products overview page as a permanent redirect (301) for that node. While this can be dome manually (in Drupal minus the 301) in various ways, does a module exist for this already or how would I best go about this?

This is probably best done at the web server level (e.g. a redirects.conf that's loaded by the site's vhost) and not in Drupal. It's possible to manage this in the database with something like Path Redirect (D6) or Redirect (D7) but it adds some more overhead that isn't necessary or particularly desired.

So long as the redirects are 301s, it won't impact overall SEO.

Path Fallback

stevenator's picture

I agree with @Christefano about this being a bug since the alias entry should be removed from the table on the delete op. I would say that when a path alias cannot be found, the path is then stepped up until the next level is. So, if your urls are built in such a way (SEO optimized IMO) that you have something like:

products/type/product-A or products/product-A

the fallback after the node is deleted would be to:

products/type or products

That provides a nice methodology for landing pages and forced redirects (granted without a 301 so it doesn't solve the issue). At the very least a 404 shouldn't be present. If a redirect is necessary then it should be part of the url scheme anyway as users are likely to delete backwards on a url by themselves

Thanks christefano and

el_reverend's picture

Thanks christefano and stevenator,

I have to say that I updated the node path alias BEFORE deleting the node, so I will have to try this again to confirm if I actually have an error or if it was just my mistake.

As far as the URLs go they are built as 'products/product-name' and the 'products' URL will show all available products, where the 'products/product-name' only show that particular node. However, if the URL alias for a product is deleted the old URL 'products/cool-product' will no longer be available and result in a 404, not an automatic redirection to the URL 'products'. Is this something that can be done "automagically"?

As far as managing redirects on a server level, would it be prudent to invest time to see if this can be automated (Node deleted in Drupal -> new entry is written to redirect file)? I'd rather redirect users to a overview page of all our products than end up in a 404. However, the other option is to redesign the 404 to inform the user that product is no longer available, but instead suggest another popular choice.

My experience

stevenator's picture

My experience has been that when a url path does not exist Drupal falls back up the path. Of course if the alias does exist then Drupal will return an internal path that will 404 (node/XXX that was deleted). So, no automagically will not work if an internal path is returned.

Managing redirects on the server level sounds like it would require too much overhead as a lookup would be necessary to verify the 404 status before serving the alternative node. I have never had to do such a thing, but I assume that it would/could be accomplished in a custom module. you may get better traction with using something like Fast 404s. you lose the ability to make custom recommendations, but looking down that path might give you ideas.