SEO Rankings flying all over the place, and why is this..

[Traaginen]

I agree it happens

That is pretty much reason enough not to completely abolish it. I'm not going to go drudge through my history and fetch examples as you've already admitted it happens. You don't have to believe that it occurs frequently, but it has happened to me several times today (granted I'm a power Google user) and I'm willing to bet others have had similar experiences. Generally it's going to appear when you're searching for something more specific than the example phrases you provided. Phrases with lower traffic, possibly, but if you're beating out Yahoo Answers and Apple's own forum/site for common Iphone queries you probably don't have much to worry about with SEO anyways.

Should page 1 get more "juice" than the following pages? Yes. Should only page 1 be indexed? No, not in my opinion. Several of your other suggestions are great and they could help, but I have to disagree there.

Things that can be agreed upon (for the most part)...

• Despite being superior in many areas, IPB is lagging behind competitors in SEO (at the very least in some areas of it).
  

None of us really know why, and although we can have threads like this guessing at the issues... I don't think anything less than a consultation with some Google engineer writing the algorithm is going to answer anything definitely.

[Matt]

I know what I need to do now.

If there is an issue with Google getting confused over pages it's because we're not being clear enough. We use the page__ suffix to denote pagination but also to find a specific post, etc. It pollutes the pagination structure.

So the fix for 3.4 is quite simple:

Introduce a static and unique page identifier in the URL: topic/123-test-topic/page-2/
Move the "Page X" closer to the topic title in the <title>
Add "Page X of series - " in the meta description
Clean up internal linking so it correctly uses the topic FURL with an anchor where possible
Use a query string for all other variables so if we do need to find a post, we can do /topic/123-test-topic/?p=123

This should send a clear signal to search engines and reduce confusion.

[Axel Wers]

Introduce a static and unique page identifier in the URL: topic/123-test-topic/page-2/

Yes, I agree. This is a good solution.

[Enkidu]

You've not proven anything, you've just misunderstood a lot about this topic and SEO in general.

First, <title> tag is FAR more important than the <h1>, VB has page 2 in the title.

Second, VB pages are being seen as part of the same thread, IPB are not, which is the issue here. This is what will be causing the penalisation.

Third, why would having page 2, in a title, make page a top keyword? It would not, I assure you.

Maybe I take too much for granted but it's quite astonishing how little people know about SEO. IMO as a webmaster, you should better understand this stuff.

where did you see <title> in my post? I was talking about h1

[Enkidu]

No, because the page 1 of that thread, the original thread is showing at the top of Google for the title:

http://www.google.co...iw=1348&bih=755

Same for this, and the third example is too generic a title to rank for.

Does this prove that it is worth testing?

I have just checked some sites on: xenforo.com forum software too, which is also becoming popular, and they do exactly the same with page numbers:

page-6, for example.

I don't think having 'page' in the title of every thread would be detrimental, not if this is the standard of known forum software, proven to rank very highly indeed, and the standard of acceptance by Google.

Enkidu, what are your suggestions to fix the obvious duplicate content issues, and the string issues, which is the same issue?

I need these fixes ASAP, and I am also prepared to pay anybody who can fix these issues, then I will never upgrade again, and just stick with what I know to work.

I don't have any of the issues you guys describing in this thread and I'm using 3.1.

[Matt]

Just a note to say that for 3.3.3, I've made the following changes:

- Moved the "Page X" in the <title> to just after the topic title.
- Added "Page X of Y - " into the meta description.

[AngryDeVo]

I have not read the whole thread, also I am by far no self called SEO-Expert. I have a basic understanding but never would call me good at SEO or something. But I see that IPB has huge problems with SEO, and that kinda sucks.

I just want to ask, why don't you use the same links as XenForo, I mean XF has by far the best SEO of all Forum Systems out there.

Links for Forum:
http://xenforo.com/community/forums/announcements/

Link for Threads:
http://xenforo.com/community/threads/xenforo-1-1-2-released.27329/

So for IPB it could be:
community.invisionpower.com/topics/seo-rankings-flying-all-over-the-place-and-why-is-this.363264

And than
community.invisionpower.com/topics/seo-rankings-flying-all-over-the-place-and-why-is-this.363264/page-2

for the Sites.

Why don't you use that method?

[Matt]

I am by far no self called SEO-Expert

I mean XF has by far the best SEO of all Forum Systems out there.

The two seem contradictory? :)

The minuscule benefits gained by restructuring our entire FURL system, forcing Google to drop millions of indexed pages, the hassles of 301 redirecting old to new formats and the general hassle of breaking hundreds of templates are simply not worth it.

If XF has good SEO (and what constitutes good is entirely subjective), then it's almost certainly not solely based on having the topic ID at the end of the link.

[AlexJ]

Just a note to say that for 3.3.3, I've made the following changes:

- Moved the "Page X" in the <title> to just after the topic title.

- Added "Page X of Y - " into the meta description.

If possible can you please post the patch for this one so we don't have to wait till 3.3.3 and in the mean time we can make sure if patch works or not? Thanks!

[Steven UK]

Please guys.

This situation is NOT **just** about page issues. The indexing/conflicting of [strings] instead of original page 1 of threads, is just as damaging, as they too are competing just as much as page2+, etc. Sometimes more so.

Matt, is there anyway I can have a temporary fix to stop search engines indexing any type of thread string, other than the first page of a thread?

Also, when is version 3.4 due out?

Thank you.

If possible can you please post the patch for this one so we don't have to wait till 3.3.3 and in the mean time we can make sure if patch works or not? Thanks!

I also feel this situation is way too serious to wait.

[Steven UK]

[color=#ff0000]I am going to place this small test here on this thread.[/color]

As of right now, a thread that was created yesterday is position 6 on the first page of Google, right underneath their own website, and in front of many competing websites for the same keyword:

http://www.google.co...iw=1262&bih=738

There are no {strings} attached, and there is only one page on the thread. Hopefully it won't change. There are no tags associated, and it is just static now, and SHOULD stay that way.

Let's check it day by day, to see what happens to it.

And there we have it.

My test thread has been sandboxed by Google, never to see the light of day again. And so have 3 other threads created around the same time as the one above.

My forum is a sitting duck to be de-indexed at this rate, due to these errors, and if that happens, well, let's just say I won't be happy, but at the very least our efforts are being destroyed, and the forum is most definitely being penalised.

[realmaverickuk]

I know what I need to do now.

If there is an issue with Google getting confused over pages it's because we're not being clear enough. We use the page__ suffix to denote pagination but also to find a specific post, etc. It pollutes the pagination structure.

So the fix for 3.4 is quite simple:

Introduce a static and unique page identifier in the URL: topic/123-test-topic/page-2/

Move the "Page X" closer to the topic title in the <title>

Add "Page X of series - " in the meta description

Clean up internal linking so it correctly uses the topic FURL with an anchor where possible

Use a query string for all other variables so if we do need to find a post, we can do /topic/123-test-topic/?p=123

This should send a clear signal to search engines and reduce confusion.

Perfect. Out of the box the best solution.

Remember to add Canonical from /topic/123-test-topic/?p=123 to /topic/123-test-topic/ unless that's already in place?

Would love a future option to nofollow page 2+, I'm really keen to see what impact it would have in a post Panda world. Both Rand Fishkin and a Google employee recommend it.

Anyway, some great steps Matt!

where did you see <title> in my post? I was talking about h1

Because you were worrying about the <h1> when it doesn't matter nearly as much as the title.

Please guys.

This situation is NOT **just** about page issues. The indexing/conflicting of [strings] instead of original page 1 of threads, is just as damaging, as they too are competing just as much as page2+, etc. Sometimes more so.

Matt, is there anyway I can have a temporary fix to stop search engines indexing any type of thread string, other than the first page of a thread?

Also, when is version 3.4 due out?

Thank you.

I also feel this situation is way too serious to wait.

Steven, the solution Matts posted will address the entire situation. Query strings are not an issue, the way IPB currently handle them are. As long as a canonical tag links back to the non-query string version, we're good.

[Steven UK]

Steven, the solution Matts posted will address the entire situation. Query strings are not an issue, the way IPB currently handle them are. As long as a canonical tag links back to the non-query string version, we're good.

Just looking at the stats. I have a feeling it is going to take too long to get this implemented, and that I will have to decide where to go from here. We are getting a real hammering.

I have just been checking something. This is FAR worse since the last 2 updates, the beta, and then the final 3.3.2, because the majority of the threads we created before we upgraded have not been affected nowhere near as much as near all the threads have since the last 2 updates.

[Enkidu]

In webmaster tools you have the ability to tell Google to discard a query string. I think it is called URL parameters.It is good to also note that Google will "learn" with time which parameters return the same page and discard them.

[Steven UK]

In webmaster tools you have the ability to tell Google to discard a query string. I think it is called URL parameters.It is good to also note that Google will "learn" with time which parameters return the same page and discard them.

Not practical to do that for every thread, and every string in webmaster tools. And as for Google learning which parameters? You already stated that you have not upgraded since 3.1? therefore you are not seeing these issues, and when traffic is being dramatically lost, and threads vanishing, waiting for Google is not really the solution.

I would like to know a timescale for 3.4, please? Almost every new thread created is being sandboxed on my forum within 2 weeks, so time is an issue.

[Marcher Technologies]

what you ask is accomplish-able with the robots.txt file... isn't it Steven?

Disallow: /*page__

Disallow: /*pid__

Disallow: /*st__

Disallow: /*#entry

Disallow: /*unread

[realmaverickuk]

Wow, I was just about to post the same thing. As a temp solution. My robots.txt is full of IPB stuff that hasn't been ironed out yet.

[realmaverickuk]

However

[color=#880000][size=2][background=rgb(248, 248, 248)]Disallow: /*unread[/background][/size][/color]

That's a little too generic. That will catch the word unread, anywhere in any post. Add something a little more specific. Otherwise you'll catch threads and posts that you didn't mean to i.e I have an unread book on making money for sale..

[Steven UK]

what you ask is accomplish-able with the robots.txt file... isn't it Steven?

Disallow: /*page__

Disallow: /*pid__

Disallow: /*st__

Disallow: /*#entry

Disallow: /*unread

Wow. I am shocked that I didn't think of that, and shocked that nobody else but the great Marcher provided that.

I will try it, create some threads and see what happens.

Thank you Marcher Technologies

Let's see what what this does. It will be interesting.

[Enkidu]

Not practical to do that for every thread, and every string in webmaster tools. And as for Google learning which parameters? You already stated that you have not upgraded since 3.1? therefore you are not seeing these issues, and when traffic is being dramatically lost, and threads vanishing, waiting for Google is not really the solution.

I would like to know a timescale for 3.4, please? Almost every new thread created is being sandboxed on my forum within 2 weeks, so time is an issue.

I also don't have these issues on my demo board (running 3.2).

here is the search result for tag:IP.Board:
http://enkidu.ipbhos...arch_app=forums (nofollow)

however when I do:

IP.board site:http://enkidu.ipbhost.com

I don't see that particular page ranking first.

[Steven UK]

I also don't have these issues on my demo board (running 3.2).

here is the search result for tag:IP.Board:

http://enkidu.ipbhos...arch_app=forums

(nofollow)

however when I do:

IP.board site:http://enkidu.ipbhost.com

I don't see that particular page ranking first.

Well, the issues are there obviously, that has been established.

[Marcher Technologies]

However

That's a little too generic. That will catch the word unread, anywhere in any post. Add something a little more specific. Otherwise you'll catch threads and posts that you didn't mean to i.e I have an unread book on making money for sale..

you are quite correct.

Disallow: /*/*/page__

Disallow: /*/*/pid__

Disallow: /*/*/st__

Disallow: /*/*/#entry

Disallow: /*/*/unread

above assumes a structure like here of IPB at root... and i'm simply trying to provide options for him.
also.
here's an article on the problem really illustrated in a nutshell, and why ... its realistically not a good idea at all to let search engines use search, or filters.. ever.
pagination, I am meh on, cause google crawls the post contents for search terms.... as stated, the answer sought is easily on page 20.
http://ghita.org/sea...ent-issues.html

[realmaverickuk]

Few things to keep in mind.

1. Robots.txt prevents the pages being crawled, NOT indexed. A page can still be indexed. Though over time they will likely get dropped. But not nearly as fast as a noindex robots meta tag.

Block with Robots.txt - Don't bother visiting the URL, but feel free to keep it in the index & display in the SERPs
Block with Meta NoIndex - feel free to visit, but don't put the URL in the index or display in the results

It can also cause the results to stay in the index, and display as only URL's.

2. You'll be wasting a lot of link juice, on pages that you don't want indexed and Google can't crawl.

So ultimately, it's not IDEAL and worth considering those points above.

[Axel Wers]

what you ask is accomplish-able with the robots.txt file... isn't it Steven?

Disallow: /*page__

Disallow: /*pid__

Disallow: /*st__

Disallow: /*#entry

Disallow: /*unread

Beware of this #
It's denied mark in robots.txt file. If you put that mark to any place in your robots.txt file you will block all robots completely.

[realmaverickuk]

Beware of this [color=#ff0000]#[/color]

It's denied mark in robots.txt file. If you put that mark to any place in your robots.txt file you will block all robots completely.

# is used to comment in a robots.txt file. Not block all robots.

However, # needs to be at the start of the line to be classed as a comment.

# Sample robots.txt

    User-agent: *

    Disallow: /