Thanks for expanded comment - this helps a lot.

Here's how I would love to see this implemented..

Custom Resource Not Found Page

Add a new functional page named, "Resource Not Found." Only one of these would be allowed. We can edit the content of the body, and optionally use a token to display the resource url to in the body. The page would be displayed with the full site chrome (menu, header, footer, and such) as any other page. This way, if a visitor is displayed an RNF, they will be more likely to stay on the site.

Redirections

Add a new sub menu to the Web pages menu in the admin view named, "Redirections." Display a grid of paths and the page that each path should redirect to. The system should detect requests to one of these paths and send a permanent redirect to the path of the mapped page. Multiple redirection paths could be associated with any page, providing a lot more flexibility.

In general, I'd love to see a lot more grid edit support. Needing to individually open each page to edit things like title and description is very time consuming.

Resource Not Found Log

Add another sub menu to the Web pages menu named, "RNF Log". Each time the custom RNF page is displayed (as described above), add the time, resource path, and referrer to a log file (XML?). This tab would show the log in a grid. We could see the individual requests, but also view the grouped values (individual paths & counts, individual referrers & counts). The referrers would help us reach out to others to fix links when viable.

For any given resource path, we could use the interface to easily map it to a page going forward, which would be added to the Redirections tab.

There would be buttons to clear and export the log.

Custom URLs don't really help much when the old page was either a (partial) member directory list or an individual member profile. 301 redirects would fix this. 404s are counterproductive.

Thanks, it never occurred to me that I could put the extension on the custom URL! I'll try it.

Hi Judy,

I am not sure why are you saying that .asp or .htm extensions are a problem. You can use Custmo URLs feature in Wild Apricot and have any page with custom Url like contact.asp or about.htm

We can't rename new pages the same as the old pages because the old pages have an .asp or .htm extension. Without something like this, we just totally lose our old search engine standing and have to start over. As other's have commented, old links may be broken with no way to recover. I think this is an important item.

I have merged several threads related to same problem

I would appreciate comments from everyone if this is an important need for your organization.

Hi Roger, Not quite sure exactly what you mean. We have a custom domain name registration through a third party and it points directly to the IP address of WA. We have no other hosting. Since the .htaccess file needs to go in the top level directory of your host, and we don't have access to this through WA, we cannot add one.

This problem is exactly why we are waiting to get friendly url's prior to migrating. As far as I can tell, being able to recreate all of our pages with the same url (ending in .html) as they currently have will eliminate any 301/404 issues. We create the new site to mirror the old, repoint the url, and we migrate seamlessly.

I can see where a custom 404 page gives a nice package effect for someone that types an incorrect url.

I'm assuming from your comments that the 301's would be created on the WA server, since any other place would be useless once you migrate over to WA. I could see that the 301 redirect could be useful for someone that is revamping their site and changing their url names I suppose. But you could basically do the same by just keeping the pag/url in place and re-purposing it.