That's a trick that used to occasionally work, but there's no evidence for it in the past couple of years. Google has gotten pretty good at understand how pages are rendered and is no longer completely dependent on source-code order. In some cases, they may even view it as manipulative.

Unfortunately, no - still pretty limited on travel - if I take a trip, it's usually to the Moz office. Speaking at MozCon in July and then in the Czech Republic in November.

There should be no real difference, in terms of Google's infinite scroll solution. If you can chunk the content into pages with corresponding URLs, you can put any source code on those pages - text and/or images, along with corresponding alt text, etc. Once you've got one solution implemented, it should work for any kind of HTML. Not sure why images would be different in this case.

There are also ways to create photo galleries that can be crawled, mostly using AJAX. It's complex, but here's one example/discussion:

http://www.cometton.com/thoughts/optimized-photo-galleries/

By assigning a URL to each virtual "page", you allow Google to crawl the images, done correctly. What Google is suggesting is that you then set up rel=prev/next between those pages. This tells them to treat all of the image URLs as a paginated series (like a mutli-page article or search results).

My enterprise SEO friends have mixed feelings about rel=prev/next. The evidence of it's effectiveness is limited, but what it's supposed to do is allowing the individual pages (images, in this case) to rank while not looking like duplicate or near-duplicate content. The other options would be to rel=canonical these virtual pages, but then you'd essentially take the additional images out of ranking contention.

This infinite scroll + pagination approach is VERY technical and the implementation is well beyond Q&A's scope (it would take fairly in-depth knowledge of your site). Honestly, my gut reaction is that the time spent wouldn't be worth the gain. Most users won't know to scroll, and having 10-20 pictures vs. just a few may not add that much value. The SEO impact would be relatively small, I suspect. I think there may be easier solutions that would achieve 90% of your goals with a lot less complexity.

I don't think the risk of harm, done right, is high, but: (1) it's easy to do wrong, and (2) I suspect the benefits are small at best. I think your time/money is better spent elsewhere.

That depends on a lot of factors. Consolidating those to one page has advantages, SEO-wise, but you're losing the benefits of the photo page. I lean toward consolidation, but it really depends on how the pages are structured in the navigation, what sort of content and meta-data they have, etc. I'm not clear on what's left on Page A currently, but the biggest issue is probably dilution from the extra pages. Since there are "guide" pages, though, I'm not sure how they fit your site architecture. To remove 200 of them, you may need to also rethink your internal link structure.

Yeah, I don't think the picture- and video-heavy pages are going to rank all that well by themselves. It's just a question of whether those additional pages are diluting your MLS listing pages (by using similar regional keywords, etc.).

At the scale of a large site, it's hard to tell without understanding the data, including where your traffic is coming from. If it's producing value (traffic, links, etc.), great. If not, then you may want to revisit whether those pages are worth having and/or can be combined somehow. I don't think "combined" means everything on both pages gets put onto one mega-page - you could pick and choose at that point.

Just one adjustment to this - although I think David's right that the canonical tag can be a good solution. Although Google can index https: fine, the issue is whether you're creating duplicates. If you have duplicates, then it's possible that the https: version could be the one you want as canonical. In this case, it doesn't sound like it, but I just wanted to point that out.

Of course, long-term, you should sort out why these are being created. A desktop crawler like Xenu or Screaming Frog may be the best bet, but I'd hit the WordPress forums, too. Odds are it's a common issue. Typically, it happens when some deeper page (like a shopping cart) on a site is secure, and then the links are all relative ("/about.php", for example). Then, those links get crawled as both secure and non-secure.

Unfortunately, I'm not a WordPress expert, so I can only speak in generalities.

I assume these are pretty deep in the site structure, so I don't think those "links" being reported are very powerful or important. Some people claim that, since PageRank is recursive, you don't want to cut off paths, but when the paths are deep I've rarely seen any evidence to support this. A big, bloated index full of thin content, especially content available on other sites, is a much bigger danger.

I would not recommend using both a NOINDEX and a rel=canonical on these pages. It's a mixed signal, and that can cause Google to ignore one or both signals (and at their choosing, not yours). I think NOINDEX is fine here. I've built structures like this for things like event websites (where we index the main event but NOINDEX all of the cities/dates, because they change so often) and have never seen any major issues. Actually, in one notable case, even before Panda came along, the site's rankings improved measurably.

Yeah, I'm somewhere in the middle on this one - as Richard said, an off-topic domain with low authority isn't going to buy you much. If you want the domain for the name or something, great - but don't expect much SEO benefit. Google has gotten pretty savvy about ignoring this stuff, as buying and redirecting domains has been heavily abused. I doubt you'd be at much risk here, but you'd probably see very little benefit.

To clarify, that's the official stance - rel=canonical should only be used on true duplicates (basically, URL variants of the same page). In practice, rel=canonical works perfectly well on near-duplicates, and sometimes even on wildly different pages, but the more different you get, the more caution you should exercise. If the pages are wildly different, it's likely there are more appropriate solutions.

I haven't heard any SEO recommendations or benefits regarding rel="contents". Rel=prev/next has mixed results, but I'd generally only use it for its specific use case of paginated content.

I guess you could treat V2 as "pages" within V1. If you did that, what you'd need to do is treat the main page as a "View All" page and link to it from each author page. I'm not sure if that's the best approach, but it's more or less Google-approved.

If the site has decent authority and we're only talking 100s of pages, I might let them all live in the index and see what happens. Let Google sort it out, and then decide if you're ok with the outcome. If the site is low authority and/or we're talking 1000s of pages, I might be more cautious.

It's hard to speak in generalities - it depends a lot on the quality of the site and nature of the pages, including how much that content is available/duplicated across the web. One problem here is that author pages with lists of books probably exist on many sites, so you have to differentiate yourself.

What was happening when they were parked - were they 302-redirected or was it some kind of straight CNAME situation where, theoretically, Google shouldn't have even seen the parked domains? Trick, of course, is that Google is a registrar, so they can see a lot that isn't necessarily public or crawlable.

Did the additional domains get indexed while parked, or after you went to 301-redirects?

Oh, and how many domains are we talking (ballpark)?

Ugh... 75 is a chunk. The problem is that Google isn't a huge fan of 301-redirecting a bunch of new domains, because it's been too often abused in the past by people buying up domains with history and trying to consolidate PageRank. So, it's possible that (1) they're suspicious of these domains, or (2) they're just not crawling/caching them in a timely manner, since they used to be parked.

Personally, unless there's any link value at all to these, I'd consider completely de-indexing the duplicate domains - at this point that probably does mean removal in Google Search Console and adding Robots.txt (which might be a prerequisite of removal, but I can't recall).

Otherwise, your only real option is just to give the 301-redirects time. It may be a non-issue, and Google is just taking its time. Ultimately, the question is whether these are somehow harming the parent site. If Google is just indexing a few pages but you're not being harmed, I might leave it alone and let the 301s do their work over time. I checked some headers, and they seem to be set up properly.

If you're seeing harm or the wrong domains being returned in search, and if no one is linking to those other domains, then I'd probably be more aggressive and go for all-out removal.