Bad legacy with site navigation, suggestions needed (brainstorming)
-
In order not to hurt your site I would not do number one or number two unless the category is extremely relevant which in this case I would err on the side of caution choose number two if you are going to consolidate.
- 301-redirect to the first page of the category
- create canonical tag with URL of first page of the category
- return 404/410
Again I will have a lot more information for you in less than day.
Tom
-
-
This post is deleted! -
Let's have a look here:
- 301-redirect to the first page of the category - this would alleviate content duplication issues and it would consolidate SEO authority in a powerful way. The redirected pages would become completely inaccessible for users and search engines (the remaining pages would rank better, the footprint of potential ranking URLs would decrease - there may also be UX issues)
- create canonical tag with URL of first page of the category - this would alleviate content duplication issues but would only consolidate SEO authority very weakly. If different pages gained different backlinks, you may end up with 1-2 averagely ranking URLs instead of one URL which ranked better. That being said, UX issues would be avoided as the other pages would still be navigable. Again though, this would decrease the number of 'rankable' pages (when a page uses a canoncial tag that points elsewhere, it tells Google not to index the active URL)
- return 404/410 - If you return 404, Google will probably fill your search-console with 404 errors. Internally linking to 404 URLs is a no-no, it will impact site-health metrics. 410 will let Google know that the pages are 'gone for good' yet your internal link structure may continue to contradict that statement by linking to 410s. I wouldn't recommend either of these really, especially if you wouldn't update the site's link architecture
- your suggestions? - because you're talking about paginated content (e.g: https://poweredtemplate.com/powerpoint/templates/next/25/1/index.html vs https://poweredtemplate.com/powerpoint/templates/next/25/2/index.html) - I would recommend using rel=prev/next instead of using any of the above. You could potentially use prev/next in combination with canonical tags, but it might not be necessarry. Tell Google which URLs are 'pagination' (page-based) addresses. Let Google determine how it wishes to handle them. If the problem spirals out of control and one category ends up containing literally thousands of variants based on pagination; use a wildcard-based robots.txt rule to support your pagination changes. You'd basically want to block pagination URLs, but ONLY when they started reaching ridiculous numbers (like page 1,507 or something)
-
This post is deleted! -
-
Aha, I see what you are saying but I have something for you to consider. There will be UX issues unless you delete these buttons (boxed in red). Otherwise, users will think they can navigate more pages, click a button and get redirected back to the first page. This may make them think your site is broken and cause a conversion-rate drop-off (bad)
-
We're both agreed on this. Google still has to access a web page to find that it has a canonical tag on it, thus it doesn't control crawl-rate very well. For that you need robots.txt, which stops Google from even crawling a page in the first place!
-
Yeah this one wouldn't be the best solution. Let's steer around that one
-
Yeah but, Google won't give 'as much' crawl budget to 'paginated' URLs once they are identified. This means that on the off-chance one is high-value, it still can be indexed. But Google won't spend hours and hours trying to index them all (unless they have a surplus of crawl-time, in which case they may explore further). It's kind of less harsh. It's like "Google, this page is just another version of another page. Now, if you really want, if you're sure - you can index it, but don't waste loads of time in this area" if that makes sense. It's less forceful and I never like to 'force' Google too much. Where I am saying to deploy prev/next is between paginated URLs of the same listing size only. So you wouldn't prev/next from a 50 to a 200, only from a 50 to another 50 (and from a 200 to the next 200, if they exist). Your suggested implementation looks right to me, page 2 should prev/next to pages 1 and 3. You are **right **that Google will see, both pages just have 50 entries. But they're different entries (not the same 50)! What if the templates on page 2, are (as a group) more popular than the ones on pages 1 or 3? So it would be nice for Google to be allowed to make a choice, if they want to do that (hope that makes sense!)
-
-
1. No
The switching option won't redirect visitor to page with old numbers in URL. The parameter will be stored in session/cookies and the start page of the directory will be opened. So, user won't be able to get a wrong page from the website navigation.4. Sorry, then I didn't quite understand the essence of your idea:( We already use prev/next in pagination for 50 or 200 items on page.
-
1.) Understood loud and clear! So that makes a lot of sense, that actually makes redirect options more viable
which is good4.) Got it. If you're already doing that and still having problems, either consolidate (using the 301s idea) so that it won't be a big problem, OR leave things as they are but use robots.txt to 'sculpt' the depth which Google can crawl paginated URLs to
At this point I'm thinking 1 is sounding better all the time
-
Thank you a lot for sharing your ideas and suggestions! I appreciate that

-
Hi Surge,
I created the image with a pro version of Screaming Frog SEO Spider https://www.screamingfrog.co.uk/seo-spider/ ( it's a local tool that you have to configure on a server or bigger sites)
However given the size of your site I prefer to use https://www.deepcrawl.com , https://oncrawl.com , and https://botafy.com I am currently 50% done with deep crawl which will provide more details than Screaming frog can.
I can send you some very large private files is there way to do that?
Or do you want them posted here?
sincerely,
Tom