I was checking my Google webmaster tools and notice a lot of tag pages showing up as duplicate content. It appears I had it setup to allow both lowercase and uppercase. This means Widget and widget will be 2 seperate pages.
Changing the setting doesn't alter existing tags.
I need to somehow convert all existing uppercase tags to lowercase and then 301 redirect the uppercase urls to lowercase.
I am guessing I'll need a custom mod of some kind?
- Invision Power Services
- → Viewing Profile: Topics: realmaverickuk
Community Stats
- Group +Clients
- Active Posts 275
- Profile Views 9,350
- Member Title Advanced Member
- Age Age Unknown
- Birthday Birthday Unknown
-
Gender
Male
Contact Information
58
Excellent
User Tools
Latest Visitors
Topics I've Started
Duplicate tags issue
04 May 2012 - 05:02 PM
IP.Downloads not so great SEO
23 April 2012 - 04:23 PM
IP.Downloads is brilliant, I've recently purchased it and extremely happy with most aspects of it. It does an awful lot and does it well.
However, when it comes down to the tagging + IP.Downloads, it's got some issues.
If I click a tag, for example "green", I'm taken to a page with a <title> and <h1> of "Green - Search Results". Search results isn't a particularly elegant way to describe the page. Furthermore, the fact it contains the phrase "search results" is going to reduce it's chances of being indexed. Google doesn't like to index search results.
It also lacks context. If I'm looking at invision skins, and I click a green tag, I should be shown a page about green invision skins. A title such as "Green Invision Skins on Invisionpower" and a <h1> tag of "124 Green Invision Skins available". A slight variation in the title and h1 will appear more natural and it's certainly much more contextual and SEO friendly.
Finally and this is the real issue, the sorting options result is some pretty terrible URL's.
Besides the ugly URL (which aren't the end of the world), and more importantly, it's an exact replica of the original tag page. Exact match title and <h1> tag and content.
At the very least, a rel="canonical" leading back to the main tag page, would have at least prevented duplicate content issues.
Is there any chance that these issues maybe addressed in future upgrades?
With Google being pretty harsh these days, in how they deal with duplicate content, I feel issues like this, from such a big CMS, shouldn't exist.
I will happily donate my time, to work with a developer on this.
Many thanks for reading.
However, when it comes down to the tagging + IP.Downloads, it's got some issues.
If I click a tag, for example "green", I'm taken to a page with a <title> and <h1> of "Green - Search Results". Search results isn't a particularly elegant way to describe the page. Furthermore, the fact it contains the phrase "search results" is going to reduce it's chances of being indexed. Google doesn't like to index search results.
It also lacks context. If I'm looking at invision skins, and I click a green tag, I should be shown a page about green invision skins. A title such as "Green Invision Skins on Invisionpower" and a <h1> tag of "124 Green Invision Skins available". A slight variation in the title and h1 will appear more natural and it's certainly much more contextual and SEO friendly.
Finally and this is the real issue, the sorting options result is some pretty terrible URL's.
index.php?app=core&module=search&do=search&andor_type=&sid=7ff55ef3ddc1a908b505046a6c9f095c&search_tags=png&search_app_filters[downloads][searchInKey]=files&search_app_filters[downloads][files][sortKey]=date&search_term=&search_app=downloads&search_app_filters[downloads][searchInKey]=files&search_app_filters[downloads][files][sortKey]=date&search_app_filters[downloads][files][sortDir]=1
Besides the ugly URL (which aren't the end of the world), and more importantly, it's an exact replica of the original tag page. Exact match title and <h1> tag and content.
At the very least, a rel="canonical" leading back to the main tag page, would have at least prevented duplicate content issues.
Is there any chance that these issues maybe addressed in future upgrades?
With Google being pretty harsh these days, in how they deal with duplicate content, I feel issues like this, from such a big CMS, shouldn't exist.
I will happily donate my time, to work with a developer on this.
Many thanks for reading.
How long for approval?
17 April 2012 - 02:57 PM
I purchase ip.downloads as I had set aside some time this evening to set it up and move an entire section of a forum in to ip.downloads.
However, after paying, I was informed it needs approval.
How long does this normally take?
Cheers
However, after paying, I was informed it needs approval.
How long does this normally take?
Cheers
Pretty big SEO oversight
14 April 2012 - 07:47 PM
Since updating our website to 3.2, we'd not used the mobile skin, because we wanted to "mobilize" the rest of the website, before we release it to the public.
When I first started working on it, I was a little surprised that the <H1> tags were all "sitename". The actual post title, is relegated to <h2>. I'm not entirely sure why that is, however, it's easily fixed within the templates, if you know what you're doing. However, this should be rectified, an update of the mobile skin pushed out. As most users won't even be aware the issue exists.
We released the mobile site a couple of days ago, and as I like to test things, I wanted to ensure that Googlemobile spider, was able to see the mobile website. In theory, it should be able to, as the bot by default, will pickup Android and iPhone user agents, however it wasn't. Which I guess makes the first part of the issue, a non-issue, as Google currently cannot even crawl your clients mobile skins.
In an attempt to override the default behaviour, we added the Googlebot mobile useragent, but still the mobile skin isn't being served to Google mobile.
It looks like something inside /admin/sources/classes/output/publicOutput.php is overriding it and forcing the main skin to be shown. But I'm a little scared messing about with that file.
Why is this even an issue? Having a mobile skin, will help improve rankings in the mobile search results, it's also a major positive signal to the search engines, that you're serving optimised content. But as Google has no idea the mobile skin even exists, we cannot benefit from it.
Surprisingly, I cannot find a single thread on this topic, which means it's likely nobody even knows there is an issue.
No doubt, there is some logic as to why you chose to serve Googlebot mobile the full skin, but honestly, it needs to be changed.
So to recap, the following should be changed:
1.
Needs changing to
2. <h2> titles, need to be changed to <h1>
3. Google mobile spider, needs to be served the mobile skin. (not quite sure how yet, hoping you'll be able to tell me).
On a more positive note, glad to see you listened to my advice, and extend the paging beyond <prev> and <next>. Hopefully, this is also default, in IPB 3.3.1?
Thanks for listening.
When I first started working on it, I was a little surprised that the <H1> tags were all "sitename". The actual post title, is relegated to <h2>. I'm not entirely sure why that is, however, it's easily fixed within the templates, if you know what you're doing. However, this should be rectified, an update of the mobile skin pushed out. As most users won't even be aware the issue exists.
We released the mobile site a couple of days ago, and as I like to test things, I wanted to ensure that Googlemobile spider, was able to see the mobile website. In theory, it should be able to, as the bot by default, will pickup Android and iPhone user agents, however it wasn't. Which I guess makes the first part of the issue, a non-issue, as Google currently cannot even crawl your clients mobile skins.
In an attempt to override the default behaviour, we added the Googlebot mobile useragent, but still the mobile skin isn't being served to Google mobile.
It looks like something inside /admin/sources/classes/output/publicOutput.php is overriding it and forcing the main skin to be shown. But I'm a little scared messing about with that file.
Why is this even an issue? Having a mobile skin, will help improve rankings in the mobile search results, it's also a major positive signal to the search engines, that you're serving optimised content. But as Google has no idea the mobile skin even exists, we cannot benefit from it.
Surprisingly, I cannot find a single thread on this topic, which means it's likely nobody even knows there is an issue.
No doubt, there is some logic as to why you chose to serve Googlebot mobile the full skin, but honestly, it needs to be changed.
So to recap, the following should be changed:
1.
<h1> <a accesskey="1" rel="home" title="Go to community index" href="http://community.invisionpower.com/index.php?">Invision Power Services</a> </h1>
Needs changing to
<div id="headerOrWhatever"> <a accesskey="1" rel="home" title="Go to community index" href="http://community.invisionpower.com/index.php?">Invision Power Services</a> </div>
2. <h2> titles, need to be changed to <h1>
3. Google mobile spider, needs to be served the mobile skin. (not quite sure how yet, hoping you'll be able to tell me).
On a more positive note, glad to see you listened to my advice, and extend the paging beyond <prev> and <next>. Hopefully, this is also default, in IPB 3.3.1?
Thanks for listening.
IP.Chat error?
09 February 2012 - 05:07 PM
Suddenly my chat room, when clicked, throwing the following error:
Any ideas what might be causing it?
[#CSTART-0] There was an error connecting with the chat room. Please notify an administrator.
Any ideas what might be causing it?
- Invision Power Services
- → Viewing Profile: Topics: realmaverickuk
- Privacy Policy
- Community Rules ·




Find content


