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 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 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 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 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

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.

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

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