-
AuthorPosts
-
February 8, 2019 at 10:52 pm #1064781
Good afternoon
Within Enfold I set our custom 404 page to be our Front Page.
Google Search Console as well as Screaming Frog SEO Spider, both then began showing that our homepage was returning a 404 even though the page itself worked and displayed fine.
This indicates that Enfold/Wordpress automatically return a 404 whenever the page set to be the custom 404 page is called up, even if that page isn’t accessed due to a real 404 error. This is obviously improper.
Further, after the Custom 404 option was disabled a 404 error was still being returned any time the homepage was accessed. That error finally went away when the Custom 404 option was reenabled, a different page selected, and the Custom 404 page disabled again.
This indicates that Enfold/Wordpress is returning a 404 on the selected page even if the Custom 404 option is disabled, which is also improper.
Perhaps it’s not best-practice to use one’s homepage as a 404 page, but it certainly isn’t best practice to return a 404 on one’s homepage either. It would probably be advisable to introduce a check to determine whether or not the page selected as one’s custom 404 page is also set to their Front Page, and if so, do not return a 404 error.
Thanks.
February 11, 2019 at 9:34 pm #1065688Hey uniorusa,
I am not sure that I understand all the process and the steps that we have to reproduct the issue.
have you switched homepage to an other page and then u got a 404 error?Best regards,
BasilisFebruary 13, 2019 at 7:00 pm #1066592Hi Basilis –
In Enfold, under Theme Options, enable a custom 404 page and set it to a home page, as one might if they simply wanted 404s to get rerouted to the website home page.
Then, using a crawler such as Google Search Console, Screaming Frog SEO, AHrefs, or SEMRush, request a crawl of the site.
Even though the site is displayed in one’s browser, the server returns a 404 on direct requests to the homepage.
For example, let’s pretend I own https://kriesi.at/ and using Enfold I set the custom 404 page to be the home page. A visitor then tries to access a page that doesn’t exist, let’s say https://kriesi.at/thisPageDoesNotExist/ and rightfully receives a 404 and gets shown the homepage. No problem there.
That visitor then requests https://kriesi.at/ and though they’re shown the homepage, the home page is returned with a 404 error that just happens not to be visible to the user, but is visible to search engine crawlers.
This likely has an impact on search rankings.
Does this clear things up?
February 18, 2019 at 10:40 am #1068255Hi,
Thanks for the info.
Do you have a staging site where we can see this issue? We can set the header status manually if you choose to redirect non-existing pages to the home page via the theme’s 404 option, but we need to see the issue first. I’ll tag the dev team to this thread.
Best regards,
IsmaelFebruary 18, 2019 at 9:40 pm #1068605Please see the link in the private content area in this reply. I’ve set up a clone of my site and modified the Custom 404 to be the home page, as described above, and as you’ll see from the screenshot also linked in the private content it does return a 404.
Thanks
February 19, 2019 at 11:00 am #1068867Hi,
Thanks for reporting this.
As a first step can you try to update to 4.5.4 – there has been some changing in the logic for 404 and maintenance mode page handling.
But I will open an issue to recheck this also.
Best regards,
GünterFebruary 19, 2019 at 6:44 pm #1069060Thanks, Günter. I wasn’t aware those changes had been made. I have been working off the changelog published on themeforest. For that matter, the detail page on themeforest says the latest version is 4.5.1…
Regardless, I’ve updated the test site to 4.5.4 and using the “Redirect to selected page” option I get a 302 followed by a 404 once redirected, as shown in the screenshot linked below. I believe a 301 redirect would be better for SEO and probably more applicable since if a URL isn’t found (necessitating the 404) it is more likely to require a permanent redirect (a 301) rather than a temporary (302).
Using the new “Display selected page without redirect” results in a 404 as before.
And lastly, turning off the Custom 404 option still doesn’t remove the 404 header from normal page views. It appears that even if the custom 404 option is disabled. My guess is it’s got something to do with these two lines in
class-avia-custom-pages.php
// if( ( avia_get_option( 'error404_custom' ) == 'error404_custom' ) && ( 0 != avia_get_option( 'error404_page' ) ) ) if( 0 != avia_get_option( 'error404_page' ) )
It seems to be the check to see if a custom 404 is enabled has been commented out and now you’re only checking to see if the page exists. Since the
error404_page
option (probably) isn’t unset when the custom 404 option is turned off, any request for thaterror404_page
id will always return a 404. Perhaps the better way to handle this would be to unset theerror404_page
option.Or, a simple check to see if the page selected as the custom 404 page is also the home page would likely solve all 3 problems.
Thanks
February 20, 2019 at 4:06 pm #1069510Hi,
Custom pages are special pages that are excluded from search, sitemap creation, indexing, …. and are not accessible for not logged in users –
return 404.
Therefore I personally think it is no good idea to have a custom 404 page as frontpage. Better is to duplicate the content into an own page.As our theme has to stay compatible with other plugins like WPML and YOAST implementing a solution for that in core would make us problems.
But I added filters to core that allow you to modify the behaviour to your needs.
You find the modified file: https://github.com/KriesiMedia/enfold-library/blob/master/temp_fixes/Enfold_4_5_4/custom404/class-avia-custom-pages.php
If you use WPML you also need: https://github.com/KriesiMedia/enfold-library/blob/master/temp_fixes/Enfold_4_5_4/custom404/config-wpml/config.php
The filters are:
avf_show_inactive_special_pages
avf_404_supress_status_code
avf_forced_reroute_to_404avf_404_redirect_status
avf_maintenance_redirect_statusI added the same changes to our dev repo – so they should become part of the core.
I hope this helps you.
Best regards,
Günter -
AuthorPosts
- You must be logged in to reply to this topic.