#1122 – Table in URL

Hi

SH404 is creating lots of URLs with some strange titles I do not recognise. Can I delete these URLs in URL manager? If so do I need to use the purge button.

sh404SEF absolutely never create any URL. All those URLS are created by Joomla (as non-sef) and then Joomla asks sh404SEF to transform them into SEF URL before displaying them.

I assume what you are talking about is the following:
- you have a link to a category blog, something like: /first-category, with a non-sef like: index.php?option=com_content&view=category&layout=blog&id=12
- then in the URL manager you find links like /table/first-category, with a non-sef like: index.php?option=com_content&view=category&id=12

Again, sh404SEF did not create the second URL. The second URL is there because somewhere on your site you have a link to this category. As you can see the second one is different because it's missing the &layout=blog part. It's a link to a category list view.
Often, such links appear in the breadcrumb for instance.
If you are sure you never will display a category list view, then you can clear the "Default table view name" field in sh404SEF configuration:

After clearing that field, you can either Purge URLs, or just delete the bad URLs.

2 - Google is not involved in your web site URL and Joomla. sh404SEF is internal and creates the SEF version of a link when Joomla asks it, before displaying a link on a page.

3 -

I don't recognise these as content. How are these redirects being created and how do I know which pages to redirect them to?

Those are 404. They are not redirects and are not created. They are simply recorded as they happen.
If I go visit your site and enter in my browser an address such as http://yoursite.com/hello-ian-how-are-you, then you will see in the 404 URL manager a record for 'hello-ian-how-are-you'.
It's just a record of whatever requests where made to your site.

4 - However the sample you showed looks like they are coming from your own site rather than an external requests, so you may have bad links on some of your page

index.php/component/mailto/'

that's a link to the mailto Joomla component, but it was created (in your content, or in a menu) with a leading index.php/, which is wrong. Again, we don't know if this is your own creation or just some random request sent to your site

'%22data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+gAAAHCCAYAAAB8C+OdAAAG50lEQVR4nO3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAAAAAAAA

%22 is code for a space. This one can also be either a bad URL to an image (typically in your template) or again just some random request made to your site.

Rgds

Hi

Yes, basically you can now see all of the URLs created on your site by Joomla, while with just Joomla you simply don't see them, so that's a lot.

Purge: If I use 'purge' does it recreate new URLS for the entire content on the site? If this is the case then any URLs indexed in search engines would be redundant - is that correct?

URLs are created on demand. When Joomla wants to display a link on a given page (of course there are many links on each page: one link per menu item, and then other links inside your content), it asks sh404SEF to transform it from non-sef to SEF. The SEF link can then be inserted by Joomla inside your article text, or in your modules, etc. When all of this is done, the page can be displayed to the user.
So after Purging, URLs are recreated as Joomla needs them to display pages that are requested by visitors. For instance, if you purge, and there's a page on your site that's never visited, then a link that only exists on that single page would never be created.

I'm not sure I understand what you mean by "redundant". Search engines simply record the content of pages displayed by your site, they have no idea of who or what craeated that content (a link inside a page is just a piece of content). What matters more is that when a search engine has found a link on one of your page, and then requested it to index its content, the link should always work and never change, so that S.E. finds the content again when it visits next time, or shows this page as a possible search result to a searcher.

404s: I get what you mean now about the request just being recorded. Does each request mean that the user was either automatically redirected to the closest page to the request or were they presented with the sef 404 page.

No, by default,we don't redirect; We display to users a nice error message (that you can customize) and offer them a small list of valid URLs on the site that looks similar to the URL they requested.
I strongly suggest you read the corresponding section of the documentation, you'll get a good overview of how this works.
Auto redirecting is an option, one to use with caution as it's good when it works, but it may (will) fail sometimes and then your visitor is even more lost. When auto redirect is enabled, we also display a message to inform the visitor they have been redirected, so that they understand what happened.

Rgds

Hi

So purging all of the URLs would create new URLS which could be different from the previoulsy indexed ones?

"indexed"? I don't think again I understand you question. sh404SEF doesn't know what has been indexed or not and I don't know either. What "indexed" URLs are you talking about?

When you purge URLs, sh404SEF will create the same URLs as it has created before, unless you change parameters such as "add a .html suffix" or "Insert article id", or many other settings.

Regarding the 404 requests - it would be best practice to monitor the requests and redirect them manually?

Yes, you should monitor them regularly. And I'll do the same reply as my first one: many times, it's good to have 404 and you should do absolutely nothing. If a page doesn't exisit, then having a 404 is exactly what should happen.

Rgds

Hi

We were worried that purging all of the URLs, which we take to mean deleting them, would lead to new and different URLs being created, which in turn would cancel out all the previous SEO work.

Purging means indeed deleting URLs (except manually customized URLs).

However, given the same set of settings, sh404SEF can only recreate the same URLs.

Rgds