Tedster, thank you for sharing that great information. We write long articles and have been trying to resolve the problem of how to split them up.

Some ideas off the top of my head, as long as one is manually fine-tuning each page's SEO:

Strategically choose cut-off points that are cliffhangers of a sort, to encourage readers to click to page 2.

Place any ads on subsequent pages NOT at the top, or in any place where they might interrupt the easy continuation of access. Readers going to page 2 might be engrossed enough to be irritated at the loading interruption but not so engrossed that they won't just click out. I find that when I first navigate to a site, I don't mind a bit of a wait to load the page, but if my attempt to navigate the site is met by similar lag, I'm outta there.

For certain kinds of articles - highly structured, with clear subsections, and not perforce linear - provide a brief quick links / table of contents with subhead titles spanning all the pages of the article that can be navigated from each page, or at least from the top of the first.

An option for readers, once landed, to view the whole article as one page. (Well, they do it for ecommerce product listings, why not for content? Is there a duplicate content issue? Fear of copying & pasting?)

In-text links to subsections of article, clearly delineated as part of the same article.

What I haven't seen, but what I'd like to see as a user, is some kind of cue right there at the top of page 1 that this is a multi-page article, and maybe even an option to take a shortcut.

Thanks - I'm happy my efforts hit you in a good place.

One thing I forgot to mention is that we do NOT let the internal page titles affect the file path. So, based on research that shows it to be a low level relevance signal, we abandoned any concern for getting the keyword in the file path. If the article's first page is /title-words then page two is /title-words-2. As our results showed, this convention did not create a major ranking handicap. In addition, it is a very big help on the back end - because all the URLs for a complete article are immediately obvious and easily grouped.

For certain kinds of articles - highly structured, with clear subsections, and not perforce linear - provide a brief quick links / table of contents with subhead titles spanning all the pages of the article that can be navigated from each page, or at least from the top of the first.

Yes! We do this for some of our articles too, but not for all. We've been use the left column near the top, but it could work on the right or even in a floated div.

An option for readers, once landed, to view the whole article as one page. (Well, they do it for ecommerce product listings, why not for content? Is there a duplicate content issue? Fear of copying & pasting?)

Always possible - but I haven't tested this. A print version in PDF format is something we use, and that we keep out of the index. I would suggest doing the same for an HTML version. You don't want to cannibalize the search ranking effect of the individual internal pages.

In-text links to subsections of article, clearly delineated as part of the same article.

We do this sometimes, whenveer it feels useful to the reader - but we don't do it routinely.

What I haven't seen, but what I'd like to see as a user, is some kind of cue right there at the top of page 1 that this is a multi-page article, and maybe even an option to take a shortcut.

The numeric navigation we use serves this purpose very nicely. The number for the page the user is on is highlighted - usually a bold white number against a dark background. The other numbers are clearly links with redundant visual cues in their hover behaviors.

So at first glance, the user sees "OK, I'm on page one of a ten page set of pages". We also include "Page 1 of 10" in a small font just below the <h1> element.

A lot of those steps are for usability more than SEO. But good usability means happy visitors, and happy visitors means more backlink potential.

Superb article Tedster, and I'm quite sure it would have a major beneficial impact on many sites.

One key point is that it may well work best when the whole site is paginated this way. An attempt to experiment with a couple of sets of articles may not succeed.

What works for me was an index of sub-pages (short text link) in the top left of every page, always in the same place and same format. I did have back / next at the bottom of each page.

It may be a bit laborious but why not gave each page in an article an appropriate name, not just widget1 / 2/ 3 etc? Many moons ago I did include the page number as well but dropped it through laziness.

Good stuff, nomis5. Nothing wrong with "Back | Next" as long as that's not the only navigation.

I'm curious why you think this approach would work better if it's site-wide.

I am curious as to how you make the determination as to when something should be page 2 of a multipage article, and when something should be a separate article itself.

For instance, I could imagine an article called The History of Widgets

Page 1 might be widgets up to the bronze age.

Page 2 might be history of widgets up to the middle ages

Page 3 would be widgets from Renaissance to 20th century

Page 4 would be widgets in modern and contemporary period.

But where do you draw the line that a page would be a benefit from being a page 2 or page 3 or page 4 in a multi page article called history-of-widgets-3.html, and when should it stand on it's own (e.g, Renaissance-widgets.html)?

I think what I am asking here is that could the major SEO benefit be less from the page titles / file names, and instead be more derived primarily from the interlinking?

Also, I do have one other question regarding point 9 of tedster's original post:

rel="next" and rel="prev" link tags are also included in the <head> section

Sorry if this is a stupid question, but are there acutal head tag elements that are called next and previous? Seeing the <head> has me thinking that it somehow has to go between the opening and closing head elements?

Or are you using head to refer to the page design and links to the other pages in the series?

do you use any other link types (rel attribute values) besides next/prev such as start/contents/section/...?

planet13, check out the link relationships parts of this documentation:

Links in HTML documents:
http://www.w3.org/TR/html401/struct/links.html [w3.org]

Thank you for the link relationships document, Phranque.

Also you may examine to [code.google.com...]

Great advice Tedster!

One question, how did you deal with the

/article-name

vs.

/article-name[b]-1[/b]

potential Duplicate Content issue for links pointing to "Page 1"?

Thanks a lot for sharing this Tedster, a very interesting read!

Great advice Tedster. We've been doing pagination for 8 years and I'm now realizing we've been doing it wrong! At least in regards to search visibility. We always just looked at it from an end users perspective, making articles easier to read by braking them up into manageable chunks. Kind of forgot about their search value until now.

Good studff.

I can't stand this nor do i visit/read sites that do this.

Its Not fun to read, it gives the impression the website is milking every CPM it can for advertising and it slows down everything..

Seems like a rather dubious way to increase visitor time, CPM and site breadth.

I have actually done this web page format before and have had some success.

I think the only thing you left out tedster is the ROI. In my webspace it is getting harder and harder to get a good return on one's hard effort.

In addition to rel="next" and rel="previous" I use canonical url on paginated articles.

If the goal of pagination is making chunks more readable for users, why not have the whole article on one page, then use progressive enhancement with JavaScript to show/hide the different sections of the article?

That way search engines see the whole article on one URL, all link juice flows to one URL, and you can even give the option to users who know how to scroll to skip pagination altogether.

Depending on your advertising package, you could probably refresh the ads as well on each "page."

If the goal of pagination is making chunks more readable for users, why not have the whole article on one page, then use progressive enhancement with JavaScript to show/hide the different sections of the article?

I know it is completely legit, but I hate hiding text. I try to do as little as possible just to avoid problems. But I'm a overly superstitious type. =)

I think there are a hundred ways to skin a cat, but the point Tedster is making is a good one. He was able to get more visibility in search for his content by treating subsequent pages more uniquely than he had in the past.

It is advice that is valid for many situations beyond this one.

how did you deal with the /article-name vs. /article-name-1 potential Duplicate Content issue

In this case we don't resolve article-name-1 - it is 404. The URLs are created manually rather than automatically generated, so it's not a complex set-up. For automated URLs I suppose a 301 could be instituted to strip the "-1" from any requested URL.

We also use the canonical link tag, so that alone would probably be enough in most cases.

This is interesting to read about. I did some pagination on a particularly long article a few years back, but I did things a little differently. Each page has a root common h1 title (the actual original title of the whole article) with the addition of e.g. " - part 1" at the end. Then there are 1 or more unique h2 headings on each page, since each page is not dedicated to only a single subsection of the article. There's a page menu just above the h1 with abbreviated, keywordy links, title attributes (again unique but each starting with a common root not matching the h1) and no link to the current page. This is repeated at the end of the main page content, mainly for user convenience. All title and description tags are unique and do not quote the h1 heading text. There are no rel="next" or rel="prev" tags. Also the page filenames are unique-key-word-type names, loosely related to the title tag content, with no numbering.

These pages have worked well but I'll certainly review them in light of this post though. Thanks.

75% of the articles on one of my "now sold" sites was between 3 and 7 pages long. I used a very roughly similar pagination system as Tedster suggests.

The reason for doing it site wide rather than a small % as a test is that (absolutely no proof) Google seemed to understand what the relationship was between the pages if it was done on a large scale, sitewise.

I did get sidetracked by the BBC, copying one of their pagination schemes. Same principal but the links were in very different positions on the page. It failed miserably. I converted the pages back to the original positioning and page views increased.

For that site I'm talking about, all this occurred over extended time scales, typically 3 to 6 months before I saw any results. But this may be because of the subject matter of the site.

I believe that correct pagination makes the best use of the content available where there are long articles. Possibly I'm ignorant, but the use of H1 and H2 never had any effect on my site and I did some experimentation. This also refers to long term rather than short term experimentation.

Ican't stand this nor do i visit/read sites that do this.

Its Not fun to read, it gives the impression the website is milking every CPM it can for advertising and it slows down everything..

Not necessarily, a long time ago I decided to split my "Seventies Movies" section into "Seventies Movies A-E," "Seventies Movies F-O," and "Seventies Movies P-Z," because they're lengthy (156K, 152K, and 144K respectively) pages of mostly text (did the same thing for my "Seventies TV" pages). As I added content to them over the years to get them to this size, I think my visitors appreciate the fact that I don't have a single movie page that's 452K big. I know I personally hate visiting blogs that seem to have endless content on a single page where the webmaster makes no attempt to purge older content.

@Tedster
can you explain these a bit further:

rel="next" and rel="prev" link tags

@Bewenched:

@Tedster
can you explain these a bit further:

please look at the link that phranque provided at post #5

Links in HTML documents:
[w3.org ]

(I don't know if I have enough privelages to post working links in my posts)

Thanks for the amazing post Tedster.

Thanks Tedster -- brilliant post.

Two related questions:

1) do you know of anyone who has done tests or studies that address the usability issues of such a pagination scheme? Obviously a lot depends on the presentation, but it's quite easy to see ways that it could be a negative (more clicking required) or a positive (knowing where you are, what the sub-topics are, etc.).

2) A few of the sites I work with have great content and terrible bounce rates. Of course the writers say "A bounce is a single page -- we have given them everything they want in one view" and I can only reply "well, maybe -- it could also be that they're not interested, or scared away, or only read the first few words, or ... who knows?" -- seems to me that this scheme would not only reduce bounce rate, but would give a whole new dimension to understanding how engaging an article is. Any thoughts on that?

Again, great stuff. Thanks!

I don't know of another study just off-hand - it's hard to keep enough of the variables fixed so you can isolate just what you want to focus on.

I can tell you about some data I have from an earlier project in online medical writing. We found that 5 screens worth of scrolling was the sweet spot for pagination. It generated more read-to-the-end visits than any other page size. That was without some of the usability enhancements I tried in this more recent case.

You can't use word count or character count to decide on page breaks, since the width of the display is an essential variable that changes the read-through data.

When it comes to bounce rates - the big challenge is how well qualified is the traffic to begin with. That's one reason I really like read-through rates for paginated articles. If someone starts an article, and then goes to the next page, and then the next - now you've got some data you can sink your teeth into. Taken in aggregate, you've got a much better metric than a single page article where who-only-knows leaves the page whenever.

Each new page in a paginated article is a kind of "mini-conversion". And when it comes to bounce rates, I would never let a client back away from serving their MOST INTERESTED target just because others bounce away. As I'm quite fond of saying, you can deposit a percentage point in the bank. You only deposit revenue, and that comes from your most interested visitors, not some generic, random person (or bot!) who happens onto a page.

tedster. You once again show me why you are the man. You pretty much reaffirm to me what my suspicions were. I always knew that pagination was bad for websites especially when the pages offer little unique content. This looks highly automated, something google does not like.

Do you have any experience with changing current articles and making them more unique with this approach and seeing a fast effect from google recognizing the change?

Starting my own similar study, tedster you interested in being part of it? :)

Nothing exactly like that - no. Sorry. I could blow some smoke around on the topic, but I'd rather not ;)

going to experiment on a site I have been neglecting. Will let you know how it goes.