Welcome to the Q&A Forum

Hi Charles-Olivier,

Thanks so much! We're very excited to get this first version launched. Re: French - the database won't be nearly as comprehensive for suggestions as it is in English. That's not to say it's useless, but the tool is certainly English-language-centric at this first launch. In the future, we hope to add support for other languages and regions, too.

p.s. Québec is one of my favorite cities in the world; if there's ever a great marketing conference there, tell them to invite me! Would love to visit again.

Yes! If you've got a high-level Moz Pro account, you'll get 15,000 queries per month. Go nuts!

Hi Stuart - in the search bar, on the right-hand side, there's a drop down to change the search engine. Unfortunately, volume data is for US only right now, but we're looking into expanding that over time.

If you're signing up for a new Moz Pro account at $99/month, it's only 5 queries/day. But, if you had a $99/month account before today, we've granted legacy access at 300 queries/month. At $149/month (or the $600/year standalone), you get 5,000 queries/month, and access goes up from there.

Thanks Dmytro! If there's any features or functionality you'd love to see added, let us know

Howdy gang - as you probably saw, we launched our biggest new tool in Pro in many years today: https://moz.com/explorer

If you're a Moz Pro subscriber, you've already got access. We went ahead and gave folks who were at $99/month before today 300 queries/month. If you're signing up new, $99/month doesn't have KW Explorer access, but the other levels - at $149/month and above, do (5,000+ queries/month).

You can read the blog post here for lots of details, but if you have questions or product suggestions, please don't hesitate to ask!

Radi - I hear you, dude. OSE's backend index, Mozscape, hasn't kept up as well as I'd like with being able to process as much of the web's links and pages that we need to get a comprehensive picture. I think that's why a lot of folks also use Ahrefs and Majestic to bolster their link data. Mozscape is good at a few things those others aren't - Page Authority and Domain Authority are quite good (very well correlated with Google's rankings), Spam Score is a very useful metric, and OSE has a lot of metrics like MozRank and MozTrust that you can't get elsewhere.

But, the downside is that calculating those metrics is a hugely computationally expensive process. Every few weeks, Mozscape takes all the links and URLs it's seen the last 90 days and starts a processing run that takes 20-30 days. When it finishes, we get a new index. We can't overfill that system with too much data, or it breaks What we need is more resilient, real-time system that can scale with hardware, and that's what the team's been working on.

In the months ahead, you should see Mozscape improve (particularly for US and English-language links and websites), and around the end of the year or beginning of 2017, we expect to have a system that can process large numbers of links in real time.

Apologies that our tech hasn't kept up with the needs on this. Despite a huge investment over many years, we've not yet been able to launch what's needed, but we're relentless and we'll keep at it until we get there. We know it's too important to give up on.

Not too big a problem to have slightly longer title. Just be aware that how they display in SERPs can affect CTR, which can affect rankings. You can use https://moz.com/blog/new-title-tag-guidelines-preview-tool to get a good view of that.

Hi JoaoCJ - In cases like these, I don't usually sweat the URL length too much. It is OK to go over a bit -- our recommendations come from correlation analysis and testing. Observing Google's rankings, it tends to be the case that pages with fewer parameters (like 0) tend to outperform pages with more, and that shorter URLs tend to outperform longer ones. That said, it's not a hard and fast rule, more a sloping line.

As far as the filters go, I might consider using rel=canonical unless you're sure you want those pages separately indexed. If that's the case (you DO want them indexed), perhaps consider using static URLS -- even something like a number in the URL could work, e.g. /123/.  For the pagination, Google's also got the rel=prev/next tags that I'd suggest employing.

Wish you all the best!

Hi BStone - apart from the obvious (it's manipulation and might violate Google's TOS/webspam guidelines), there's also a bunch of other items to consider:

• Google has access to Android and Chrome user/usage data to see which clicks are real/not real
• The referrer string would be passed along from wherever you placed it (and it wouldn't come from a validated, Google.com address)
• Google can see search query data and knows when a query has actually hit their server (and all sorts of details about where/from whom). Artificial inflation of those, even in our tests, only had a very short lifespan in terms of influencing SERPs (see https://moz.com/blog/impact-of-queries-and-clicks-on-googles-rankings-whiteboard-friday and https://moz.com/rand/queries-clicks-influence-googles-results/ for more details)

Thus, IMO, this isn't a pragmatic or effective way of influencing Google's perceptions of clicks/CTR.

No, that's not correct at all. As you can see from the other folks replying in the thread, and from reading my post and responses, we're simply saying that DA is a relative measure, not an absolute one. It's like ranking websites based on their visits rather than showing their raw number of visits. You could grow your site traffic by many thousands of new visitors, and still have a lower "rank" because others grew their traffic even more. That's just how relative metrics work.

I wish I had an answer to that If I had to guess, I'd say sometime in the next 2 years, but not anytime in the next 9 months. We've stopped asking the team for a final delivery date because it's just too hard to estimate all the work required, and past estimations have been so far off target. Instead, we just try to estimate the next quarter worth of sprints and then measure how we perform against those.

It turns out, replicating a processing system like Google runs without billions in revenue is really hard

Hi Kevin - the index update should be live as of right now (probably only a few hours after you posted this message). We aim to have one index update per month, so 12 per year. We had a catastrophic failure on our early January index, so it had to be abandoned (noted here: https://moz.com/products/api/updates), but the team has been working hard to fix issues and prevent others from arising. Unfortunately, it's often the case that we encounter new/unexpected/never-before-seen issues that need to be addressed. Frustrating, but unavoidable as best we can tell. Obviously, we will continue to do our best to get these indices out on time.

As far as the future goes, it's hard to say. We have a bigger team now than we last year -- 4 folks work full time on the Mozscape index and 4 are working on the next-generation version of the index (which will update in near-real-time), and we certainly have much better monitoring and operational structures in place. But, as I noted above, it seems that the errors/issues we face are always new and unique - things we've never seen before in the 100+ index runs we've had over the last 8 years. I can tell you we're building processes to identify problems before they happen, and that we're better staffed, and that we have engineers on-call 24/7 to fix issues if they crop up, but processing full-graph metrics on a full-scale web index whose shape and composition can vary wildly means there's still uncertainty and probably always will be. Our job is to keep reducing that uncertainty and finding optimizations, while we rebuild the full system in the background to eventually replace the old, batch-processing system that's at the core of so many of our challenges.

Hope that helps.

In my experience, the best way to absolutely get rid of them is to use the 410 permanently gone status code, then resubmit them for indexation (possibly via an XML sitemap submission, and you can also use Google's crawl testing tool in Search Console to double-check). That said, even with 410, Google can take their time.

The other option is to recreate 200 pages there and use the meta robots noindex tag on the page to specifically exclude them. The temporary block in Google Search Console can work, too, but, it's temporary and I can't say whether it will actually extend the time that the redirected pages appear in the index via the site: command.

All that said, if the pages only show via a site: command, there's almost no chance anyone will see them

14 months! Wow. That is a long time indeed. Although, now that I look, Moz redirected OpenSiteExplorer just about a year ago, and we still have URLs showing for the site: command in Google too (https://www.google.com/search?q=site%3Aopensiteexplorer.org) so I suppose it's not that uncommon.

Glad to hear traffic and rankings are solid. Let us know if we can help out in the future!

Oh gosh - it's my pleasure! Thanks for being part of the Moz community I'm honored to help out.

As for the URLs - looks like everything's fine. Google often maintains old URLs in a searchable index form long after they've been 301'd, but for every query I tried, they're clearly pulling up the correct/new version of the page, so those redirects seem to be working just great. You're simply seeing the vestigal remnants of them still in Google (which isn't unusual - we had URLs from seomoz.org findable via site: queries for many months after moving to Moz, but the right, new pages were all ranking for normal queries and traffic wasn't being hurt).

Some examples:

• https://www.google.com/search?q=Enter+the+World+of+Eichler+Design
• https://www.google.com/search?q=Eichler+History+flashbacks
• https://www.google.com/search?q=eichler+resources+on+the+web+books

Unless you're also seeing a loss in search traffic/rankings, I wouldn't sweat it much. They'll disappear eventually from the site: query, too. It just takes a while.

Hi Rosemary - can you share some examples of the URLs and the queries that bring them up in search results? If so, we can likely do a diagnosis of what might be going on with Google and why the pages aren't correctly showing the redirected-to URLs.

Yeah - my blog - moz.com/rand has the Wordpress install on Moz's site, on the same servers as the rest of our domain, and we've implemented security protocols that make it very hardened. There's lot of WP security stuff out there that can help, and a talented sec-engineering team should be able to set it up with a minimum of problems. Many of the world's biggest companies run Wordpress, so there's lots of pre-existing protocols.

Hi Rosemary - thankfully, I have data, not just opinions to back up my arguments:

• In 2014, Moz moved our Beginner's Guide to SEO from guides.moz.com to moz.com itself. Rankings rose immediately, with no other changes. We ranked higher not only for "seo guide" (outranking Google themselves) but also for "beginners guide" a very broad phrase.
• Check out https://iwantmyname.com/blog/2015/01/seo-penalties-of-moving-our-blog-to-a-subdomain.html - goes into very clear detail about how what Google says about subdomains doesn't match up with realities
• Check out some additional great comments in this thread, including a number from site owners who moved away from subdomains and saw ranking benefits, or who moved to them and saw ranking losses: https://inbound.org/discuss/it-s-2014-what-s-the-latest-thinking-on-sub-domains-vs-sub-directories
• There's another good thread (with some more examples) here: https://inbound.org/blog/the-sub-domain-vs-sub-directory-seo-debate-explained-in-one-flow-chart

Ultimately, it's up to you. I understand that Google's representatives have the authority of working at Google going for them, but I also believe they're wrong. It could be that there's no specific element that penalized subdomains and maybe they're viewed the same in Google's thinking, but there are real ways in which subdomains inherit authority that stay unique to those subdomains and it IS NOT passed between multiple subdomains evenly or equally. I have no horse in this race other than to want to help you and other site owners from struggling against rankings losses - and we've just seen too many when moving to a subdomain and too many gains moving to a subfolder not to be wary.

Hi Juan - If I had to guess, I'd say we probably had some issues crawling the sites where your links were (most likely errors on our end, though it's possible the sites themselves had issues, too) over the summer, and we've now rectified it. We're continuing to improve with future indices, and you should see us getting more consistent about this with each release.