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

Sorry, Cesar - you're right, this thread went way off course.

My notes on 301 as preferred vs rel=canonical were strictly focused on potential "duplication issues" brought up by Federico as related to Desktop URLs. The 301, you're right, is the wrong tool for the job when it comes to Desktop/Mobile.

The page I linked to originally - here: https://developers.google.com/webmasters/smartphone-sites/details#separateurls - has the instructions you'd want to follow under "separate URLs."

To clarify with Google which page should be served to which search users (Desktop vs Mobile), you need 1) a rel=alternate tag pointing from Desktop to Mobile and 2) a rel=canonical tag pointing from Mobile to Desktop.

Effectively if you will have the same canonical for both versions - the Desktop home page. Whether or not you have rel=canonicaled the Desktop back to itself (again this doesn't accomplish much but it won't hurt you), the Mobile home page (following the instructions from Google) will be rel=canonicaled back to the Desktop home page.

And yes, if your Mobile home page has a lot of links pointing to it, using this setup should increase the overall authority and ability to rank of your Desktop home page. It will consolidate that link equity at the Desktop home page URL.

Both pages will remain indexed, but Google (learning from the rel=alternate tag) will serve up the Mobile home page only for mobile search users.

Hope that clarifies a bit. Disregard the discussion between Federico and I on the correct use of 301s in this thread, as it was off topic. In short, a 301 will not serve you well in this case. You want one of the three implementations recommended by Google on the page I linked to above (and in your case, the third option for separate URLs sounds best to me).

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

A 301 is still the preferred/recommended method to point alternative URLs with exactly the same content back to the core version.

A canonical can achieve this as well, but it's not the preferred, most foolproof method to consolidate link equity and avoid duplication.

A canonical of a URL to the exact URL itself, again, achieves nothing. I'm not suggesting it'll cause some kind of problem (Google/Bing have been able to handle this from the beginning without any "infinite loop" issues), just that this in itself doesn't solve anything.

What you'd want is a canonical tag on those other URLs pointing back to the preferred URL. If you have no way of serving up unique source code per URL variation, then a self-referential canonical would be acceptable. But a 301 would be my first choice.

Maybe splitting hairs a bit.

In the example here, we're talking about desktop vs mobile URLs and how to handle canonical/alternate tags between the two, so duplication issues are a bit off-topic.

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

If I'm not mistaken, I believe you can simply select the "secondary variable" option in the organic search report and enter "Hostname" as the variable - which will display the root of the relative page URL for each keyword, uncovering what domain that traffic is hitting. I've used this in the past for similar GA profile issues across root/sub domains. Might be worth a shot.

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

It won't hurt to link from older articles, but I'd take a look at what kind of Page Authority / PageRank these older articles have before bothering. If new posts, without generating any new backlinks from external sites, are ending up with about the same authority as those old articles, new/old probably won't make much difference.

One thing you might want to bring into consideration is the level of traffic, and through what keywords, those old posts are getting - if they're on related topics to the pages you're trying to rank, you can channel some relevant traffic to these pages while you're building the links by creating some more visual emphasis (instead of just linking some anchor text within the post, use a call-out box to entice some clicks).

There are a lot of unknowns from my standpoint, but that's my advice based on what you've described.

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

"Indexed in Google" is irrelevant here. Sitemap protocol and the searchable web index have little to do with each other directly (sitemap files are not searchable in the web index).

If you're following the instructions on this page, you're good. Geo sitemap tags are no longer supported by Google.

Note: When I click on the link to http://www.holycitycatering.com/geo_sitemap.xml your server returns a "page not found" error, so I'm not sure where your geo URLs are located...

-Mike