Welcome to the Q&A Forum

Hi Eric,

Setting a Referrer Policy via a Meta tag, as described in Cyrus's 2015 post, is still valid.

Whether you need to use this to see referral traffic on your client's site is a question of the security protocol of both sites. If your site is HTTPS and your client's site is HTTP, setting the referrer policy as described is an option. If they are both HTTPS or HTTP, you shouldn't need to set a referrer policy.

Whether it will work properly in your case will best be determined by adding the correct policy and checking for the data in the analytics of your client's site.

Best,
Mike

Hi Kay,

These two example URLs do not seem to represent duplicate content - the listings are different for each page. I wouldn't want to set canonical tags on these pages as they are unique.

Did you see an error in an SEO tool of some kind indicating there was a duplicate content problem here?

For general applications, canonical tags should be added to the duplicate page(s) themselves, and those canonical tags should refer to the preferred/canonical page that you want to keep indexed (but no changes need to be made to the preferred/canonical page itself). So if these pages were true duplicates of your homepage, each duplicate would need the canonical tag  (but the homepage itself would not need to include the canonical tag).

From your examples, I'd just caution you may not be dealing with actual duplicate content - they look like valid pages to me.

Best,
Mike

Hi Joe,

If we create 301 redirects for the pages and content on the main site and add noindex, nofollow tags, will we lose the domain authority that we have from our original domain because the pages now have the noindex, nofollow tags?

If you create 301 redirects for pages on the main site, the "noindex,nofollow" tags will have no impact (bc they'll never be visible to Googlebot or other clients). The pages would have to load (200 status code) for Google to discover and make use of the Meta Robots tag or any other directive/content.

So if you're planning to create 301 redirects for these pages, I wouldn't bother with the "noindex,nofollow" tags - once Google encounters the 301 redirect they should index the new pages and remove the old pages.

One caveat: if Google detects a large disparity between the old and new pages (topic/intent is clearly different), the authority might not translate over to the new pages. We usually see this work fine, but it's something to keep in mind.

Best,
Mike

Hi cPanel,

You should be able to simply change the property name and URL in GA for this. You'll find basic instructions from Google here: https://support.google.com/analytics/answer/3467852?hl=en

You should be able to use this interface to update the property name and default URL for your property, keep the same tracking code in-place along with all of your historical data.

Best,
Mike

Hi CORSOLUTIONS,

I think Abogados Madrid above is right in that you're best off creating specific pages for the areas this client serves with as much local-specific information as possible.

Outside of that, without a verifiable, physical address in each local, it will be difficult to rank in the "local pack" of results - these are largely driven by "distance to centroid," or the physical distance of your business's verified location to the center of the town/zip/etc the user searched for.

In short, it's pretty tough to drive traffic without visibility in the local pack these days, but with pages for each distinct area (keyword research is a good idea to verify whether a distinct area actually has specific search volume) you have a chance.

Best,
Mike

Hi Eddie,

I wouldn't be concerned about Google making an assumption about a PBN here.

I also wouldn't be surprised, though, if you don't see the traffic you're hoping for on the "aged" domain - it's anecdotal, but I've heard no shortage of stories over the years of domain consolidations, or domain purchases and redirects, that netted out without the traffic expected. If enough changes at once, Google can hit the "reset" button on the trust they've accrued to the domain(s) in question.

That said, what you're planning to do here sounds fine by me, and if I had to bet one way or the other, I'd bet on this working (I'd be shocked if you saw any penalty from this unless the domains you're redirecting or the newly purchased domain have a history of inbound or outbound linkspam).

Best,
Mike

Hi Shop-Sq,

This is a tricky one to answer definitively without knowing the details of the two sites.

Having been through a very similar situation, I expect that, unless the content is truly identical, you're existing site shouldn't suffer any losses by having both live and indexed at once.

That said, until you properly redirect the old pages to their new counterparts, the new site will probably only see marginal growth. So running them side-by-side, you're not likely to get a good measure of how the new site will perform once you redirect.

In my experience, there's no way to handle a site-wide redirect like this "risk-free" with a smooth transition. But you'd have a chance to catch any technical issues that might negatively impact Google's ability to crawl/index the new site's content if you launch it well ahead of March, then set the redirects once you're comfortable (again I'd want to do this well ahead of busy season if possible). This will give Google some time to crawl the redirects, pass PageRank to the new site - and it'll give you and your team some time to work out any kinks.

Hope this helps at least somewhat - these are not easy situations to evaluate especially without detailed knowledge of both sites.

Best of Luck,
Mike

Hi pickeringkelly,

Typically redirects on a WordPress site are found in three places:

1. The .htaccess file (often hidden by default, this file lives in the root or home directory of your hosting account and accepts redirect rules based on URL pattern matching
2. Redirection or a similar WordPress plug-in that provides a user interface for creating and managing URL-to-URL redirects based on an exact or partial URL match
3. Within the WordPress database itself, if a page's URL (or "permalink") has been updated, WordPress will automatically set a 301 redirect to the latest page - if you have a page with a permalink/URL that has been updated several times, this could cause a redirect chain

It won't be easy to spot what's triggering the redirects from the outside, even if you provide example URLs - it's much easier to spot what logic is set up with access to the .htaccess file (in the root hosting directory) or your WordPress installation.

If this is happening across all URLs of a given type (for instance a global redirect for all http:// page requests to https:// (secure) versions), it's likely to be driven by your .htaccess file logic. If it's just a few pages and the chains are unique, it's probably handled via a redirect plugin or the built-in WordPress logic.

Hope this helps!

Best,
Mike

Hi Bob,

This is one of the woolier aspects of SEO ("quality" or trust).

One thing I'd recommend is getting familiar with Google's Quality Rater/Evaluator Guidelines: https://static.googleusercontent.com/media/www.google.com/en//insidesearch/howsearchworks/assets/searchqualityevaluatorguidelines.pdf

These are the guidelines they provide to their ~10k human search quality raters - this is the group they use to review potential changes to their search results to gather qualitative data on those results.

You'll see that there's not much "hard" data to go on here, but one way we've measured this and made it actionable at Distilled is by running surveys that we can deploy via SurveyMonkey+Amazon Mechanical Turk to get some sense of how the "average user" would rate a site across some of these points.

Here's a blog post that walks through the process: https://www.distilled.net/blog/seo/replicate-googles-panda-questionnaire-processing/

There are no universally-applicable tips here, but trust elements like badges, aggregate user reviews, testimonials, etc are good places to start. Depending on the niche, if you're dealing with "YMYL" (Your Money Or Your Life) topics, basically any advice that could have a serious impact on a person's quality of life, Google has made big shifts recently (see: "Medic" update) to prefer sites where the "experts" running them or publishing content have clean, established reputations in the space (not just accolades displayed on the site itself but elsewhere on the web). This seems to have been particularly important for sites that are offering both advice and selling "solutions" related to that advice (for example, a medical advice blog that's connected to an ecommerce site that sells dietary supplements).

Hope this helps!

Best,
Mike

Hi Mat_C,

For the HTTPS update, you'll want to ensure that all HTTP URL requests are redirected to the new HTTPS versions. Usually this can be done with a global redirect (often it's easiest to do this via your .htaccess file).

However, because you're migrating from what sounds like a HTML site or non-WordPress CMS, your page paths, file extensions, etc will also be changing - so you'll want to map redirects from the old URLs to their new WordPress counterparts more granularly. This should only be necessary for URLs that have external links (links on other sites) referring to them or URLs that users will have stored in bookmarks or will find in advertisements or other referral sources.

We usually look for URLs that have external links using a tool like Moz's Link Explorer and URLs that have Direct or Referral source traffic via Google Analytics / similar.

When you know what old URLs needs to be redirected to new URLs, there are WordPress plugins (like Redirection) that can make this easier than adding an exhaustive list to your .htaccess file or similar.

Best of Luck,
Mike

Hi Jeff,

This is a tough one. Very sorry to hear about your business losses.

As I'm sure you know, several the recent "core algorithm" updates from Google have focused on site quality. Via their Quality Rater program, they ask human reviewers, with specific guidelines, to dig not only into the content of the site but the background of the owners/writers. They test new substantial algo changes with this group before they update results for all users, with a specific focus on "Your Money Or Your Life" (YMYL) content, or pages that deal with serious and potentially life-altering topics.

A site offering health information and supplement advice, and also selling those supplements, is in the crosshairs of this kind of review.

This is just my take on it, but I expect your losses are largely due to the perceived brand trustworthiness. I'd consider toning down your on-site product promo imagery and ensuring trust-building elements (badges, ratings, testimonials, any kind of accreditations you have) are clearly visible above-the-fold. I'd also recommend building a more clear/clinical layout and typographical treatment for your advice content (blog posts, articles, etc). You might also want to consider limiting the array of supplements you promote and sell, staying away from the controversial and potentially dangerous.

I also, unfortunately, would not expect immediate results from this. These core algorithm updates come several times a year, but but I worked with an auto parts retailer who lost 30% of their organic traffic+revenue overnight in the "Phantom III" update (which seemed to be a general "quality" update similar to recent core algo updates) - they had some UX issues, content that seemed there just for SEO, etc. About a year after their big drop, they made a big push to improve UX/quality and add trust-building elements to their pages, and six months after this design/UX overhaul, they regained all of their traffic in the "Phantom V" update.

I suspect there is nothing technically broken with your site and that duplicate content and similar are not holding you back much - but that quality raters preferred search results with other sites for the keywords you've been ranking for.

First impressions of the brand, quality/trustworthiness of content, etc have big impact here - but these reviewers are also instructed to verify that the owners/publishers of the site are accredited and trustworthy as per other online sources:

"Many websites are eager to tell users how great they are. Some webmasters have read these rating guidelines and write 'reviews' on various review websites. But for Page Quality rating, you must also look for outside, independent reputation information about the website. When the website says one thing about itself, but reputable external sources disagree with what the website says, trust the external sources."

Not to suggest you have scam/similar accusations showing up online, but it's something additional I'd want to look into.

Best of Luck,
Mike

Hi Allan,

A lot of this depends on what else will be changing in this process outside of the domain name.

Probably the best and most detailed case study of such a domain migration was featured here at Moz: https://moz.com/blog/domain-migration-lessons

Individual experience varies and is always anecdotal (what happened in one or even 10 examples doesn't necessarily predict what will happen with your site). I've seen both cases where this goes fairly smoothly and cases where Google seems to ignore some portion of the link equity acquired to the old domain resulting in a net loss of traffic.

There is plenty to look out for here, but if your site platform, information architecture, content, etc are all remaining static during the domain change (recommended), primarily you're going to want to ensure you don't lose any link equity in the process by setting a global page-level redirect with 301 response codes and that all of your tracking and configurations in platforms like Google Search Console are set up properly for the new domain. On that note, you'll also want to use the "Change of Address" tool within Search Console when you make this change.

This post from Builtvisible provides some helpful detail on how to approach the redirection process - but as above, if the site is otherwise remaining static, you should be able to handle this with a global patter-matched redirect (vs the painstaking process of setting page-to-page redirects).

Where possible, if you can have links pointing to your site (on other sites) updated to reflect the new TLD, that'd be ideal.

After the migration, I'd recommend you pull a list of your top linked pages from Moz Link Explorer, AHREFS or similar, crawl the full list and ensure that the redirects are firing properly (301 response codes, single-hop redirects and the final destination URL is valid/live on the new site).

Overall, this is one of those gray areas in SEO - it's a sensitive process and I would expect a period of traffic drops as Google crawls and indexes your new pages and attributes PageRank to them properly.

Best of Luck,
Mike

Hi Remko,

Apologies for the slow response here - the alert system that lets us know a question has gone unanswered broke down for a time.

The short answer: the ideal is to render the content/information as raw HTML, then use a JS library (whatever suits the animation or chart style you're after) to visualize and add animations.

Animations handled with jQuery, for example, won't be processed/"viewed" by Google, so if you're using such a library to add polish to your content, it's best that the page "degrades gracefully" - so that without JS support, the key content/information is still there in the HTML source.

While Google has made strides in their ability to render and index content delivered via JS resources, it is computationally expensive and we have seen that relying too heavily on JS to render the content itself is sub-optimal.

If you're following the above, any modern and widely-adopted JS animation/chart-building library should be fine.

Hope this helps,
Mike

Hi Dale,

Nigel is right here - it's best practice to leave the Titles/Descriptions on these archive pages as-is and follow Google's guidelines (use next/prev link tags) to indicate paginated content.

If your concern is duplicate content, next/prev tags give Google a clear signal of the relationship between these pages.

Best,
Mike

Hi seoman,

I think Nigel is spot-on here and has summarized the issues at hand well.

One thing to add: If you do deploy canonicals but are not sure how/when Google is respecting or ignoring them, the new "URL Inspector" tool in the new version of Search Console provides some helpful (and unprecedented) reporting detail on this, including URLs for "User-declared canonical" (what you set in your tag) and "Google-selected canonical" (the URL Google opted to treat as canonical).

While there doesn't seem to be any clarity as to why Google selected an alternative, sometimes the URL they picked provides a hint. We've never had this clarity from Google before on when they've opted to select a different canonical URL, so it's good to at least know when it's happening.

Best,
Mike

Hi Brad,

As others have indicated, there's no reason a 301 redirect on a missing image shouldn't work - it's all based on the URL request (not the actual resource served, since the server intercepts the request and forwards it to another URL along with the 301 status code).

I'd second Yaroslav's recommendation on a good WP plug-in for this (Redirection). You should be able to just use the URL string here to set the redirect where you want to point it.

I would also suggest double-checking that these are actual links pointing to the image URL, not embeds of that image on these pages (some tools will pick that up as a link). 
Finally, you may want to create a new page that includes a suitable replacement image if one is available, rather than redirecting to the replacement image file URL (bc this way the reclaimed PageRank will flow through to the rest of your site via your navigation).

Best,
Mike

Hi Helen,

Other responders here are right, IMO - Search Console's "Links to Your Site" report has always been an unreliable view of actual inbound links.

We've seen strange behavior here, and often times a close inspection of the "Who links the most" URLs turns up no actual links. Likewise, we often find links via Moz Link Explorer, ahrefs, Majestic, etc that Google is not reporting.

In short, I wouldn't worry much about what Google is reporting here - we have not found a good use for this report as a measurement of actual links at Distilled and tend to ignore it for inaccuracy.

Best,
Mike

Hi Chris,

To my understanding, my take is that, unless Google Image search is an important channel for your business, the improvements to page speed/UX will be a net gain for SEO.

Using Base64 encoding for images may result in those images falling out of Google Image search, but the pages themselves are not likely be negatively impacted.

Caveat: Google has not communicated on the impact of this specifically, and we've not tested this with Distilled clients - I've based my answer on my understanding of Google's technology, their emphasis on all things page speed and the fact that this approach is growing across the web (so it's likely Google has already solved for this or else will have soon).

Best,
Mike

Hi akih,

I don't believe the "text-only" cache is representative of Google's index. They process JavaScript via their rendering service before they index content - so the full cached version is a more accurate representation of the content Google has seen/indexed.

Also, I ran a search for your site using a snippet of copy from the "Common Preservative Free" badge, and Google is returning pages with this text in the displayed page description. Here's a link to the SERP for the query I used.

I'd say Google's able to see and index this content just fine - it's just the "text-only" cached content does not include any JavaScript-rendered content.

Best,
Mike

Hi dbsmtec,

It'll be tough for anyone to tell you without auditing your particular website what's likely up here.

If you have seen a gradual drop, there could be a confounding factor afoot - UX issues, for example, are often behind otherwise unexplained organic traffic trends. Page speed is sometimes an issue with Magento - was there any negative impact on performance in the upgrade?

If the drop has been site-wide and gradual, I'd suspect it's something related to UX/user interactions that is causing the drop. If it was sudden, it's more likely (but not necessarily) a technical issue. Looking at traffic across page types can sometimes help narrow your scope.

Again, it's tough to say without looking at your particular site and performance data, and even then, I'm afraid, the answer may prove elusive.

Best of Luck,
Mike

Hi Zack,

I think your concern here is valid (your render with Screaming Frog or any other client is unlikely to be precisely representative of what Googlebot will see/index). That said, I'm not sure there's much you can do to eliminate this knowledge gap for your QA process.

For instance, while we have seen Googlebot timing out JS rendering around the ~5s mark using the "Fetch & Render as Googlebot" functionality in Search Console (see slide 25 of Max Prin's slide deck here), there's no confirmation this time limit represents Googlebot's behavior in the wild.

Additionally, we know that Googlebot crawls with limited JS support - for instance, when a script uses JS to generate a random number, my colleague Tom Anthony found that Googlebot's random() JS function is deterministic (returns a predictable set) - so it's clear they have modified the headless version of Chrome they use to conserve computational expenses in this way. We can only assume they've taken other steps to save computing costs. This isn't baked-into Screaming Frog or any other crawling tool.

We have seen that with a 5s timeout set in Screaming Frog, the rendered result is pretty close to what "Fetch & Render as Googlebot" functionality demonstrates. And with the ubiquity of JS-driven content on the web today, provided links and content are rendered into the DOM fairly quickly (well ahead of that 5s mark), we've seen Google rendering and indexing JS content fairly reliable.

The ideal would be for your dev team to code these pages to degrade gracefully - so that even with JS support totally disabled, navigation and content elements are still rendered (they should be delivered in the page source, then enhanced with JS, if possible).

Failing that, the best you're likely to achieve here is reasonable confident that Googlebot can crawl, render and index these pages - there'll be some risk when you publish them to production.

Hope this helps somewhat - best of luck!

Thanks,
Mike

Hi Anthony,

There's unfortunately no setting in Google Webmaster Tools for this.

Your best bet is to use IP detection logic to either totally block (return an error status code and no content) or serve a simple "our content is not available in your country" error page to all requests from IP addresses in the UK.

You can do this by building your own reference database or using a service - there's also some freeware). (FYI: anyone on a proxy network can get around this.)

Google does use "locale-aware" crawling, including appearing to crawl from other countries than the US (most likely through a distributed computing network), and the UK is likely high on the priority list for that.

Google should pick up on this over time and stop including your pages in search results. But it may not be immediate.

Best,
Mike

Hi rswhtn,

I can't add much more than others have here already.

Are sliders in general bad for SEO? If they diminish the user experience or slow down the page, they could hurt more than help. Technically speaking, speed is a potential reason. Since Google responds to signals of a satisfied user (and uses quality rating in their algo.), anything that impacts the user's impression of the value of a page is a potential factor for SEO.

Is Revolution Slider specifically good/bad for SEO? We have no indication Google has targeted specific WordPress plug-ins for security warnings / similar. If a site gets hacked and Google detects malware, different story, but there's no indication an unhacked Revolution Slider instance would impact SEO.

I think I'd consider UX here before SEO - are users engaging with the slider? Would they engage more with another layout? Split testing is easy and free with Google Optimize these days. Security may be an issue, but that's a valid concern with any plug-in.

Best,
Mike

Hi rswhtn,

We have not seen proof of structured data having a direct impact on general organic rankings. However, we're confident that clickthrough rate does have an impact on rankings (see Rand's Whiteboard Friday on this here, as well as Larry Kim's post). Since "rich results" (rich snippets) can impact clickthrough rate, the should then have a secondary impact on rankings.

That said, it doesn't sound like your homepage had a rich result from this use of structured data. It's also not clear whether/how Google uses this postal address data. Since it's not likely been implemented at any significant scale across the web, I'd be dubious if it were a useful ranking signal for them. It's possible, but I'd call it unlikely.

We have seen rankings fluctuate significantly across client accounts even when the pages in question have not been updated. It seems that Google's AI/Engineering team iterate on search results frequently.

So, in short, I suspect this has to do with something other than structured data.

The significant changes to the homepage may be involved (UX can have a significant impact on rankings), but these changes could very well have generated a net gain in terms of overall traffic/results in spite of this lost head term position.

Unfortunately I think easy/clear answers on this will prove evasive. If you have the data (via Ahrefs or otherwise), I'd recommend reviewing the "flux" in the top 10 search results for "clothing manufacturers" around this time. If yours is not the only result that shifted significantly in this time frame, it's like part of a larger shift in Google's ranking algorithm.

Best,
Mike

Hi Adam,

It's best to consult with your web host on this one to ensure you're working within whatever restraints/quirks their system includes, but generally speaking, a single type A name record with the host @ specifying the domain including www subdomain should take care of it.

But again, you're probably best off following instructions from your web hosting provider and/or consulting their tech support team.

Happy Holidays,
Mike

Hi vtmoz,

I see you have posted an updated question on this issue separately - regarding the spammy inbound links pointing to this subdomain. That is a more likely problem for your site.

That said, the more spam that shows up on that subdomain, the more likely Google is to seeing your site as part of a "bad neighborhood" of the web, and this could risk the organic visibility of your root domain.

There is no documentation on "how much spammy content is too much" - generally, some spammy content on a subdomain doesn't negatively impact the entire domain. However I have seen cases where an entire domain was negatively impacted by a very large number of spammy pages on various subdomains. It's a matter of scale.

If your rankings and traffic on your primary domain are important, my advice would be to mitigate the risk by either policing the content on your forum subdomains by bringing in admins, or shutting down the forums entirely.

Best,
Mike

Hi Robin,

There's no indication Google is having any trouble picking up the separate URLs and their associated Titles and Descriptions properly - a site: search for your domain returns all pages I'm able to find manually, and each page has a unique and accurate Title and Description snippet.

ReactJS is one of the most commonly used JS platforms, with a lot of momentum in the development community especially on high-traffic sites, and Google has innovated their crawl tech to include JS-support (they crawl with a headless version of Google Chrome) to adapt to this platform.

"View Source" is no longer valid for interpreting page code as Google will render it - they crawl with JS support, so JS interactions and modifications of source code are visible to Google. Using "Inspect Element" in Chrome shows a more accurate representation of what Google can crawl/render.

In short: I see no negatives for SEO here, and I expect at this point your analytics and Search Console data will show that your pages are indexed and eligible for traffic (potentially already getting traffic) from Google.

Best,
Mike

Hi Chris,

It's not entirely clear how this will impact SEO, but there is some indication hidden content could be weighted lower by Google.

Google has said in the past that such hidden content will not be weighted equally to visible content. In the early part of this blog post there's a helpful summary of Google engineering statements on this issue: https://www.freshegg.co.uk/blog/technical-seo/google/how-does-google-treat-hidden-content

It's at least somewhat likely that content contained in lightboxes will be weighted less than visible content. So while I'm not certain there is a downside, there could be and it's worth consideration for your new site design. There wouldn't be any kind of "penalty" for pages containing hidden content, but rankings for keywords/language contained in that content could be lower than they otherwise would be if the content were visible by default (without user interaction). I'd recommend planning for that.

Best,
Mike

Hi D,

As per Martijn's response, this example is a JS asset required by your WordPress theme. It's unusual that this would end up indexed by Google (even more unusual that any users would inadvertently stumble upon it - is there any indication of that?).

It sounds like there's a lot of this going on, but one thing I'd suggest initially is first verifying whether these URLs are actually getting impressions/clicks in search results via Search Console's "Search Analytics" report.

I suspect Martijn is right in that this isn't an issue worth much time/attention (a huge portion of the web runs on WordPress, Google has no trouble sorting out actual pages vs JS resources and similar URLs that shouldn't be served to users), but if there are really "a ton" of these URLs showing up, it might be worth verifying search users aren't actually seeing/clicking on these URLs so you can rest assured it's not a high-priority concern.

Best,
Mike

That's a very strange behavior I have not seen before (and I've had plenty of experience with GoDaddy and their domain forwarding).

The query workaround is interesting/clever - but I'd also be inclined to want to sort out why this is happening at all and stop it vs reworking all the domain forwards around this symptom.

Have you contacted GoDaddy's shared hosting support? I'm not the biggest GoDaddy fan overall, but their tech support team can be quite helpful in tracking issues like this down.

Hello,

As Martin suggested, it seems any option will require time and effort.

Are you sure these pages are causing an issue with duplicate content? Are they ranking and pulling traffic/sales?

I'm dubious these pages are having a negative impact. I would want to verify that as much as possible before expending the resource to canonical or take other action.

That said, canonical would be the recommended solution here - and should take no more effort than the "noindex" tag.

Best,
Mike

Hi vtmoz,

I would not fear a negative impact on the main domain from linking to poorly-optimized subdomain pages. Negative impacts from linking to "bad neighborhoods" are limited to cases where you're linking to true webspam (some examples from Google here).

At worst, you're linking to pages that won't rank well because they are not well-optimized for search, but the main site and pages will not be negatively effected.

Hope this helps clear things up.

Best,
Mike

Hi Alexandre,

Google should have no problem indexing URLs with Cyrillic characters, but it could be the mix of language that is causing Google to attempt to decode those characters.

But even if that were the case, this should not result in a 500 error but a 404 (not found) for those resultant decoded URLs.

It looks like there are 301 redirects in place for these URLs now, pointing to their EN counterparts - has that resolved this issue? Perhaps it was faulty redirect logic in the first place that caused the 500 errors?

Thanks,
Mike

The question of relevance vs authority in what makes links valuable is an interesting one and has recently been covered on Search Engine Land here: http://searchengineland.com/relevance-vs-authority-link-value-part-two-274417 (part two)

I tend to agree with those who value authority over relevance, as I've not seen any real proof that "relevant" links drive more power, but I have seen that links from off-topic sites improve rankings and traffic many times.

Obviously there's a great deal of context I don't have about how related the two sites appear to be to users that could be adding to the mess, and it does sound like the authority you have isn't quite driving the business you want, so no big pushback on the 301s - I'd keep an eye on your rankings and organic traffic though, it could cut authority to the point where you see a drop.

Best of Luck,
Mike

Hi Doug,

I'd be dubious about associating the old posts with the lack of traffic/rankings for the new store pages.

If you were to redirect those old posts to another domain, at best I'd expect no impact, at worst the loss of PageRank will cause the store to lose some the traffic/rankings it has now.

You could potentially test this (redirect those old posts somewhere else, see what happens, then remove the redirects if you're unhappy with the result, or if there's no/positive impact, leave them in place).

Ultimately, the need to acquire new links (and traffic sources other than Google) will remain either way, which is probably where I'd be investing focus/capital.

Best,
Mike

seovp's advise is spot-on here.

I'd just add that "1-2 keywords per page" is really obsolete advice at this point, unfortunately. Google is doing a better job of every day of understanding synonyms and semantics and creating associations between language, pages and entities - this kind of granular keyword targeting is less impactful every day and also could flag you up for a Panda penalty.

You are entering a saturated market for sure. Outside of SEO, I'd be investing in creative ways to sell your products as well as get attention around your brand. Even in the long tail, you will find the competition fierce for these products, so you'll really have to find a unique way of doing things to get initial attention with a smart partnerships and promotions plan, which will translate into the links/shares/traffic that send the right signals to Google and raise your rankings across the board.

Best of Luck,
Mike

Hi Nick,

I think you've gotten some good tips here - I'd agree with Prestashop that the preferred solution would be to find where these parameters are being included in links to this page and remove them.

Failing that, zenstorageunits's advice to use rel="canonical" would be my recommendation - or a 301 redirect from the URLs that include parameters back to the core URL would work.

I wouldn't convert these parameters to subdirectories unless they are integral to the way your site works and pull up unique content - you called them "old parameters" so it sounds like they're not supposed to be there, so probably not a case where you'd want to convert these parameters to subdirectories.

Failing the above, you could utilize the Google Webmaster Tools "URL Parameters" interface to tell Googlebot to ignore these parameters.

Overall, your best course of action is to find and remove the links that include the parameters.

I'd also add that the Moz crawl report is highly sensitive to "duplicate content," and I often find it flags up issues has high/medium priority that are not actually going to have a significant impact on the site. You have to take the crawl report with a grain of salt - while duplicate content can be a serious issue for some sites (ecommerce retailers for example with duplication issues across a wide catalog of products), in most cases it has minimal impact and isn't something I'd hold up your site launch for.

Best of Luck,
Mike

Hi Matt,

In general, my advice would be to achieve permanent 301 redirects at as granular a page/folder level as possible (prioritized by the current number of linking root domains - Open Site Explorer's Top Pages report is a great tool for this).

Where the rebranding & migration is concerned, I would strongly recommend reading through two resources here at Moz:  

1. Ruth Burr's overview of Moz's own fairly recent move (from SEOmoz.org to Moz.com) and
2. Aleyda Solis's handy "Achieving an SEO-Friendly Domain Migration" infographic

Between both, I think you'll have your bases covered.

Best,
Mike

Hi Matt,

Not sure I have a clear understanding of what you mean by "Could I do a 301 redirect for a couple months and then take it off and make the umbrella site?"

Any 301s you set up to pass link equity must be maintained permanently.

You can absolutely use 301s at the subfolder/page level, and if you can leave those redirects in place permanently this may be a solution for you.

The other option is to reach out to webmasters for your most valuable links and get those changed over to the new events site - can take a lot of time and isn't always successful, but it's often the best option to ensure link equity is maintained.

If you'd like to share more detail, I can circle back and provide more specific info. Hopefully the above helps to some degree.

Best,
Mike

I would recommend option #1.

It's common for sites without SSL certs not to resolve properly at the HTTPS version of their URLs, and Google handles this fine.

You could pull the log files and take a look at how often Googlebot / other users request HTTPS versions of that site A's URLs, to determine if that SSL/redirect set up is necessary. But I would not anticipate any significant negative impact on traffic letting the HTTPS version of site A kick a 404 or server error.

Thanks for the update, Conor - glad to hear you've sorted it.

Best,
Mike

Hi Jon,

As Andy suggested, I wouldn't worry about this unless you see it correlating to a significant drop in traffic on your site.

We see a lot of noise in these activity reports, unfortunately, and rarely do they directly correlate to significant losses/gains in traffic/business.

Not to suggest nothing is wrong - there may indeed be technical or other issues involved - but without a thorough crawl of the site and review of all potential issues, it'll be tough for any of the Q&A participants to pinpoint an issue.

One thing I would consider: it seems there are only 330 indexed pages on the site. This being the case, a lower number of pages crawled and kilobytes downloaded may reflect a better understanding of your site architecture by Google, or perhaps you've recently cleaned up some extraneous URLs / URL Parameters / etc? In other words, why would you want Google crawling 7k pages on your site daily, if you have nowhere near 7k pages that matter for organic search?

Again, I'd keep a close eye on your organic search traffic (Intelligence Events would be good to set up for this), but these activity reports alone don't necessarily correlate to changes in search visibility - there's as good a chance this indicates Google is simply crawling your site more efficiently than before.

Best,
Mike

Hi Irving,

As Yusuf suggested, .htaccess files are not publicly viewable - they're inaccessible by public users by default.

For your own site's .htaccess file, simply downloading the file via FTP and opening with Notepad/similar will work. But I take it you were looking for a tool to check the .htaccess file for public sites. If there is such a tool, it's news to me.

Best,
Mike

Hi Conor,

Sorry it's been so long without a response. This question was just assigned to me, but I haven't seen this issue before and can't offer any insight.

It's been a while now so you may have already sorted this.

If you're still stuck, let me know - I can flag this up to a wider group of people and see if anybody's seen this issue before. Worth a shot.

Best,
Mike

Hi Harriet,

Have you considered going GA Premium? It certainly isn't cheap $150k/yr, but the platform is proven and continues to improve. I don't know where comScore's pricing is at - I'm assuming it's less expensive than GA Premium.

Two alternatives I'd recommend looking into:

• Chartbeat for Editorial
• Parse.ly

I haven't had the chance to use either of these first-hand yet, but I've heard good things, they're designed for publishers and the interface/reporting looks good.

I'd be interested to hear what you land on and why, if you care to circle back in this thread.

Best of Luck,
Mike

Hi LW,

Sorry for the extreme delay here - the Q&A notification system went wonky for a bit and I never got the response message for this thread.

I'm sure you're passed this issue by now, but yes - Googlebot Mobile should just index the mobile version of the page.

Best,
Mike

Hi Harriet,

I've only seen this a couple of times in the past, and I was always been able to sort out what was up.

One thing I'd recommend is to make absolutely certain that the destination URL (and no other versions of it) is the only URL that's setting those UTM variables. In other words, ensure no additional pages are getting traffic for that campaign.

I'd also be curious to know how much traffic the site receives overall - if you're at the level where GA will actively sample your reports, I've seen sampling cause some wonky numbers, though it is usually proportional / within reason.

It's a few weeks now since you posted this question, not sure you're still vying with this, but if you're still stuck and can provide some more detail, I'll be happy to dig a little more.

Best,
Mike

Hi Melanie,

Definitely possible using GTM's Data Layer object, but it'll take a little work to make it happen.

Two resources I'd recommend a deep dive into to understand this logic:

1. Google's Tag Manager Developer's Guide explains how to work with the data layer - I'd consider this mandatory reading as there are a few basic setup steps for utilizing the data layer object
2. This great tutorial video from Eric Fettman at KISSmetrics (which I'm borrowing a bit from below) is a great, clear walkthrough - the whole video is solid, but if you're looking to jump right to the bit that applies to this case, go to 9:20

The following is my basic stab at what you'll need to do, but you should by no means consider this foolproof - testing and adjustment will be required.

You'll basically want to...

1. Use the dataLayer object in your form HTML to push an event with the search field value into the data layer upon the form's submission

   For example: < form name="myform" onsubmit="dataLayer.push({event','search','eventLabel':[searchvalue]});" /> where search is the name of your new custom event, which you'll listen for with a new GTM event tag & rule combo (following steps), and you must replace [searchvalue] with the value of your search form field via JS or jQuery - that last bit is a little tricky and will probably require a separate function to parse the DOM and grab the value from the search field, but I'd look at the same basic functionality that JavaScript Form Validation uses as a starting point. Maybe someone with stronger JS skills than mine can help you sort that piece.

2. Create a new event tag in GTM with custom Category and Action static values (maybe "search" and "search performed"), adding a Macro with the type "Data Layer Variable," with a Data Layer Variable Name of eventLabel (which is what we used in the HTML code above - crucial that these match) and Data Layer Version set to 1

3. Create a rule for this new tag to fire when the Condition {{event}} equals search (or whatever you've specified as the event name in your form HTML above

It can be a little confusing wrapping your head around this combination of pushing a custom event along with a dynamic event label into the data layer and using that to trigger a rule+event combo to grab that data and push it with your custom event values into GA, but when you think through the logic a few times it becomes clearer.

I'd love to hear whether this did the trick or at least led you down the right track if you don't mind circling back in this thread.

Best,
Mike

I would +1 Wiliam's answer here. 301 redirects in addition to Bing's site moving function should do the trick. Particularly if the links that point to the old domain, which will be redirected via the 301, contain your brand name - I've seen this carry the branded search rankings over regularly.

Moz has chosen to keep their home page title reading "SEOmoz is now Moz" for several months now - I don't know first-hand, but I'd imagine they've done this in part as insurance to ensure they rank for their old brand name. Might be worth considering the same.

Hi Gavin,

Chris is right in that what you want to do is set up cross-domain tracking with GA, to pass the referral information between these domains and "close the gap" with your data.

The instructions Chris linked to will help.

I'd just add this: with the combination of the new version of Google Analytics (Universal Analytics) and Google Tag Manager, cross-domain tracking is simple and easy. I highly recommend this implementation, with the caveat that if you have any custom event tracking or other customizations to Google Analytics tracking code, it may break when you move to Universal Analytics and GTM. Instructions are on this page.

The added benefit here: setting up event tracking is also very easy once you're working with the combination of Universal Analytics and GTM.

Best of Luck,
Mike