Remove / Modify / or place a Warning - Admin>Configuration>Layout Settings>Main Page-Opens with Category

[harmonyball]

This is a Suggestion for consideration and comment:

There is an inherent issue, particularly for novices / non-coders/ etc like me (call me dumb), in selecting Admin>Configuration>Layout Settings>Main Page - Opens with Category ... IF the site is established and was set up originally as default - Main Page = Main Page.
Selecting to open with a category results in the existing main page disappearing, i.e. it cannot be found by the user, admin or critically the crawlers - it responds as a 404 page not found (this is the domain url we are talking about in essence not existing)
The specific 'critical' result of the 404 is that all external links (backlinks) pointed to the domain url (main page as it was) are lost, as indeed are all internal links pointing to the domain url (beheading the internal linking structure).
So yes, I did exactly that through ignorance, wanting to see what effects it had on various site stats as an experiment - a very hard learned lesson that no-one else should have to go through, hence in my opinion that process should be reviewed.

So as per the thread title here are some suggestios;

1. Remove that function/selection - what purpose does it serve that a 301 or 302 redirect via cPanel (htaccess) would not?

2. Modify the code if possible to avert the situation described - I have no idea how the code works when that selection is made but possibly that can be modified?

3. or at the very least place a Warning when someone selects the function - a warning that shows a popup box (or similar) that says "are you sure? if you already have the default main page established with inbound links (external & internal) then they will be LOST) ... read this doc (to be written) before proceeding" .... or something similar - an in your face validation. Not just written text in the information / edit box.

The advantage of the site owner instigating a 301 redirect from main page to the category of choice is that external and internal links will follow the redirect, so no links are lost (or more accurately not able to be found by crawlers). If someone was doing what I did, trying out the open with category to see what effect it had on traffic/ conversions etc, then a 302 could be used until the 'experiment' was validated as beneficial then the 302 could be changed to 301, or if not successful then simply deleted. The site owner is in control and not reliant on the platform functionality (currently unexplained). There may be very valid technical positives to using the selection but I am unaware of any - there is no information available in Docs that I can find.

What are the likelelihood/possible chances / frequency of occurences of this happening? Who knows, but if it is only one more then that is one too many in my opinion. For all any of us know it may have happened to others without them knowing, i.e. they do not check their GSC regularly to observe the changes in external and internal links, but their site is suffering and they do not know why and look at other things. How many bother to 'report' that they had the issue (obviously now fixed, why bother)?

The point is it is avoidable.

I look forward to seeing some comments and hopefully I'll get an education along the way.

cheers, Mike

[drbyte]

The setting Main Page - Opens With Category was created before the era where hosting companies could easily allow storeowners to do redirects within their hosting control panel. It was also before the time where people would do massive SE experiments.
It's probably overdue for being adapted to being a built-in auto-redirect.

The setting takes effect only when someone visits the store's home page with no actionable URL parameters AND the Always Show Categories setting is enabled.
Its purpose was to allow a storeowner to automatically open to a specific category. The most common use of this is when a store has only one main category and therefore the home page makes sense to just show the items in that category. It was especially popular for stores that had only one product: it would be immediately in "buy" mode (or if it was a free download or document etc then it was still in immediate call-to-action mode).

The setting ALSO caused the "welcome" dialog text to be displayed at the top of the page, just like it normally would on the home page (because, er, THIS Main Page - Opens with Category category IS the home page).
A 301 redirect would lose that.

[drbyte]

selecting Admin>Configuration>Layout Settings>Main Page - Opens with Category ... IF the site is established and was set up originally as default - Main Page = Main Page.
Selecting to open with a category results in the existing main page disappearing, i.e. it cannot be found by the user, admin or critically the crawlers - it responds as a 404 page not found (this is the domain url we are talking about in essence not existing)
The specific 'critical' result of the 404 is that all external links (backlinks) pointed to the domain url (main page as it was) are lost, as indeed are all internal links pointing to the domain url (beheading the internal linking structure).

I'm actually surprised that you would get a 404 page not found by changing the setting ... because none of the URLs or canonical links are directly affected by the setting. It only changes the content that is displayed when visiting the naked URL (no actionable parameters), by displaying a certain category-listing instead of displaying a list of all categories along with various content-boxes such as featured-products and specials etc. All the displayed links and their canonical links should be reachable and indexable as usual.

[barco57]

almost 20 years using Zen Cart and have never thought of it like this. I have also known that main page with categories is a replacement for the "normal" main page, Flipping that switch makes the "normal" main page unavailable because it loads a totally different template file. Basically, the "normal" main page no longer exists... it seems obvious to me, and should be a switch in the admin.

[drbyte]

But ... the naked URL, the "home page" never disappears.

It is only its content that changes:

• when Categories - Always Show on Main Page is set at its default of 0, the home page shows only the "content centerboxes" of new/featured/specials/upcoming. AND the Main Page - Opens with Category setting does NOTHING.
• When Categories - Always Show on Main Page is set to 1 AND the Main Page - Opens with Category is set to any given category cPath, the home page ALSO shows an ADDITIONAL prime content section above those new/featured/specials, comprised of the specified category. If the category has subcats, it shows navigation to those subcats. If it has only products, it shows links to those products.

In both cases, the shell HTML, and particularly the page <head> section (which commonly contains some SEO directives) is identical.

I'm referring to the responsive_classic template. I can't speak for 3rd-party templates, which might do random other things when those switches are set.

screenshots:
first, with setting disabled:

and with enabled:

[harmonyball]

Doc, I cannot argue with your knowledge of the platform code and functions - your example above is the same as I experienced, obviously has to be. I said as much in my previous comment ... "When the site opened with the category the browser bar still showed the domain url without any extension (which is why I wasn't alerted until checking GSC)."

Not to be pedantic however it appears that the 'browsers' still saw and rendered the domain naked url in the browser bar because it did not know any different (as agreed it is just a page content change) - but definitively Google could not find it and rendered a 404 and could not find links directed to that url.

Of course I did not realise what was happening at the time otherwise I would have taked screenshots and or downloads from GSC on their reports - when I did see the GSC reports I'm afraid I went into WTF mode and then immediately reversed the function and requested Google to index the naked domain url - hindsight kicked in a few days later that maybe I should have taken a few moments to save and retain the evidential information, including a page source download.

As stated, I was/am not complaining, simply reporting my experience and suggesting a review of the function. So to my mind it is a case of you (and maybe others) needing to prove it to yourself, one way or another, as it is not making any sense to you as a developer, by way of the example of a test as suggested which will prove/disprove it definitively (not theoretically). Given that such a test will take some time, and as you suggested the real need for this is function is minimal these days, maybe simply refer to your solution in your original comment of an automated 301 (I still think it best for the site owner to make their own redirects taking the responsibility away from ZC)

[drbyte]

I was also surprised, believe me, devestated would be more accurate. However that is what hapened.

To be clear: I'm sorry that this all happened. It's one of the scariest things a storeowner can encounter.

definitively Google could not find it and rendered a 404 and could not find links directed to that url.

This is the challenging thing to diagnose, and is very tough to stage for a store that's only for demo purposes and gets no "real" traffic. Google treats inactive sites with low priority, so it's tough to even get "consistent" indexing, despite making requests for it. But even if the traffic and crawling factors are mitigated, figuring out how Google made a request that triggered a 404 on the same URL that doesn't issue a 404 when the page body (and not headers) is changed by a content switch ... is near impossible.

It smacks of "some other contributing factor" being part of the picture.
But I see you've clearly stated that this setting was the only "change" made.
Truly puzzling.

simply reporting my experience and suggesting a review of the function

Noted. And I appreciate your detailed recounting of things. It really is helpful when deep details are provided, as it helps rule out many different factors, and helps narrow things down more decisively. Much appreciated.

[drbyte]

To your point, if we can get a scenario set up where the deindexing has taken place, and we can explore the robot's index-responses in real time, hopefully the root cause will be probe-able.

[drbyte]

I know I said earlier that some redirect functionality could/should deserve exploration in regards to this feature.
However, given that the configuration switch is intended to control what is displayed, independent of redirects, I'm not going to suggest the switch 'trigger' any redirect operations.

(Obviously if we are able to determine a root-cause factor making Google read a 404 by using the switch, then whatever the switch 'caused' aside from the content-change, will be addressed and fixed.)

As far as offering the storeowner a way to do internal redirects, I think that sort of thing should start with documenting some guidance on how/when to do such a thing, using whatever tools the storeowner possesses via their hosting company. Contributions welcome in that area.
If the exercise of writing such guidance exposes some need for coding some helper features in Zen Cart, we can explore the merits of that at that time.

[drbyte]

At the outside, this discussion was proposing that a warning be offered to storeowners using this switch.

I'm willing to explore that.

At this time the most accurate statement to make in terms of a warning is akin to "while this setting only changes whether category-navigation is offered in the middle of the home page, one storeowner has reported that using this switch caused Google to de-index their home page; watch your GSC closely for impact after changing this setting".

I know it's hard to find evidence of others having the identical problem from the identical cause ... for reasons already mentioned earlier in the discussion. It could be more prominent than anyone knows.