Hidden section page still shows in web browser ....

[MrsBee]

.... but also cannot be found in FTP

I received an email from Google Search Console Team telling me about an issue on a section page which I didn't even realise was still in existence. I've had the page hidden in Sellerdeck for over three years, however it appears that the page can still be viewed online. But, even weirder, is that I cannot find this page when viewing the site via FTP.

I queried this with my hosting company but all they could do was tell me how to remove the page (backup and delete the entire 'acatalog' folder and then re-upload). Of course I can do that, but he could not tell me why this has happened and I am very curious.

Just wondering if anybody else come across this type of issue before, or has an idea as to how this happened?

[Mike Hughes]

AFAIK when you hide a page on sellerdeck it no longer generates the page and all links to the page are removed BUT I don't think it removes the existing page from the server.

Sellerdeck has a 'Purge and refresh' function in Help > Troubleshooting that should remove everything and do a full refresh.

I've no idea why you can't see the page when you ftp into your server. Realistically, the chances are it's there somewhere and you're probably just missing it.

[NormanRouxel]

If you don't see the page via FTP there may be a couple of reasons.

1) Some FTP clients only display the first n items. Likewise some servers limit the number of listings they'll send. A limit of 2,000 or 10,000 is often used. An SD site can easily exceed this number of files.

2) The FTP client's listing may be case sensitive. So machines.html and Machines.html will not appear together.

Some FTP clients allow you to enter custom commands. I use Filezilla and this works via Server / Enter custom command. Assuming I've moved into the acatalog directory, then use the custom command dele mypagename.html and the file will be gone.

[MrsBee]

AFAIK when you hide a page on sellerdeck it no longer generates the page and all links to the page are removed BUT I don't think it removes the existing page from the server.

Sellerdeck has a 'Purge and refresh' function in Help > Troubleshooting that should remove everything and do a full refresh.

I've no idea why you can see the page when you ftp into your server. Realistically, the chances are it's there somewhere and you're probably just missing it.

Hi Mike, thank you. Yes, I wasn't sure if hiding a page in Sellerdeck actually removed the file from the server, which is why I ended up in FTP looking for it only to find it wasn't there.

I really can't understand why I can't find it in FTP. The filename begins with '24mm' and I have the file view sorted A-Z. I would therefore expect to find it somewhere in amongst the session files (which I think all start with digits?). But I've looked carefully through the filenames greater than '2' and less than '3' and I just cannot find the '24mm' file. I will probably end up doing a 'Purge and Refresh' as you suggest, although I'm pretty sure I've done that at least a couple of times for other reasons in the last three years, but I'll certainly try it. Thank you.

[MrsBee]

If you don't see the page via FTP there may be a couple of reasons.

1) Some FTP clients only display the first n items. Likewise some servers limit the number of listings they'll send. A limit of 2,000 or 10,000 is often used. An SD site can easily exceed this number of files.

2) The FTP client's listing may be case sensitive. So machines.html and Machines.html will not appear together.

Some FTP clients allow you to enter custom commands. I use Filezilla and this works via Server / Enter custom command. Assuming I've moved into the acatalog directory, then use the custom command dele mypagename.html and the file will be gone.

Hi Norman, thank you.

1) My server actually defaults back to displaying 9999 files every now and again (which isn't enough) and so, each time this happens, I ask my hosting company to increase the 'LimitRecursion' setting for me. I had to ask them again this morning (apparently they've now fixed it permanently but we'll see) and FTP is now correctly showing all of the files in the 'acatalog' folder.

2) The filename begins with '24mm' so presumably case sensitivity won't be the cause on this occasion.

I use Filezilla too, so I'll have a look at custom commands. Thank you.

[Mantra]

I have been exeriencing a similar problem with Google search console error reports since 14 October 2020 - using SD V16.03.
What appears to be happening on selective sub-sections for example where I have a total 44 products listed this can be displayed as 12 products per page or all 44 products so there can be 4 separate page displays like:
productsubsectiondescription.html - all 44 product page html links or,
productsubsectiondescription-p1.html, -p2.html, -p3.html, -p4.html displayed as 12 product page html links per page.
What Google search console seems to be picking up is a display based on 10 product page html links per page so that the last 4 products with errors are listed on -p5.html.
This -p5.html page reverts to an old SD V14 design layout (10 products per page) that was upgraded to V16, 3 years ago so I am not sure what has suddenly happened to flag this up when indexes and sitemaps are kept updated on V16.
I use Smart FTP and I can see that the redundant -p5.html is still present on the server and also on the SD Site1 html files stored in program data, so I should be able just to delete these from both locations. I can see that there are a number of old dated redundant sub-section and product pages like this and I think it will be safe to delete these after taking a backup first then checking and deleting in both locations online and in the Site1 html folder.
You could perhaps carry out a similar check on Filezilla too - the product that you have hidden may still be listed on a redundant section/sub-section html page.
I would be reluctant to do a purge and refresh as I believe this will cause the site to revert to default layouts and settings with a risk of over-writing design customisations.

[MrsBee]

I have been exeriencing a similar problem with Google search console error reports since 14 October 2020 - using SD V16.03.
What appears to be happening on selective sub-sections for example where I have a total 44 products listed this can be displayed as 12 products per page or all 44 products so there can be 4 separate page displays like:
productsubsectiondescription.html - all 44 product page html links or,
productsubsectiondescription-p1.html, -p2.html, -p3.html, -p4.html displayed as 12 product page html links per page.
What Google search console seems to be picking up is a display based on 10 product page html links per page so that the last 4 products with errors are listed on -p5.html.
This -p5.html page reverts to an old SD V14 design layout (10 products per page) that was upgraded to V16, 3 years ago so I am not sure what has suddenly happened to flag this up when indexes and sitemaps are kept updated on V16.
I use Smart FTP and I can see that the redundant -p5.html is still present on the server and also on the SD Site1 html files stored in program data, so I should be able just to delete these from both locations. I can see that there are a number of old dated redundant sub-section and product pages like this and I think it will be safe to delete these after taking a backup first then checking and deleting in both locations online and in the Site1 html folder.
You could perhaps carry out a similar check on Filezilla too - the product that you have hidden may still be listed on a redundant section/sub-section html page.
I would be reluctant to do a purge and refresh as I believe this will cause the site to revert to default layouts and settings with a risk of over-writing design customisations.

Thanks for your reply. I did end up deleting the file in Filezilla last night, using the custom command that Norman provided.

However, I've just found that I have a similar page doing the same which starts with '22mm' so I've just been looking at that. The page itself in Sellerdeck is a section page without products, but with filtering applied to display products from other sections. The page name in question (when viewed in a browser) doesn't have '-p1.html' or similar appended to it so it's perhaps not the same issue that you describe, however it does sound like the same issue with regard to the page remaining on the server.

On a separate note, I'm even more frustrated that I am unable to find these files in FTP and so I'm not going to delete the '22mm' file until I've found it

[Mike Hughes]

I would be reluctant to do a purge and refresh as I believe this will cause the site to revert to default layouts and settings with a risk of over-writing design customisations.

As far as I'm aware a purge and refresh doesn't touch any layouts or overwrite any design customisations. Here's the detailed description from the help files.

Web Site Purge and Refresh...

Click this button to see some options which allow you to strip out all the files from your online store folder, and all the temporary files from your 'Site' (or equivalent) folder, and then completely refresh the store. This will disable the site for a while and should only be used if there is a persistent problem that is not fixed by going to 'Web | Refresh Website'.

[Mantra]

As far as I'm aware a purge and refresh doesn't touch any layouts or overwrite any design customisations.

Perhaps not then, but when you click the button to do this, you are presented with the warning shown in the image below:


The layout customisations should be retained but any Perl file customisations will be lost if the delete Perl Files option is checked.
I would still be reluctant to embark on a purge and refresh considering the warnings given on site downtime and no backups except as a last resort if necessary under the guidance of technical support to restore site functionality.

[Mike Hughes]

Absolutely. If there's anything with Sellerdeck you don't want to do because you don't have confidence in it then I 100% agree you should leave it alone.