Welcome to the Q&A Forum

It's best practice to minimize the amount of 301 redirect hops. Ideally only one redirect hop.

It's also best practice to 301 redirect (or at least canonical) your non-https and/or your non-www (or www) to the canonical protocol/subdomain.

The simplest (and possibly the most common) way to implement canonical protocol/subdomain redirects is through a load balancer or before your app processes the request. Both of which will just blanket 301 to the canonical domain/protocol regardless if the path exists or not

In which case, you could have:

1. Two hops. i.e. hop #1 http://example.com/foo to https://example.com/foo, hop #2 https://example.com/foo to https://example.com/bar
2. 301 to a 404. Let's say https://example.com/dog never existed, but somebody for whatever reason linked to it (maybe a typo). If I request https://www.example.com/dog, the load balancer would 301 to a 404 page.

Either scenario above should be fairly rare. However, you can't control how people link to you. Should I care about either above scenario? I could have my app attempt to check if the page exists before forwarding, but that code could be complicated.

Never said the image option was hard. It's just not ideal as it increases page load and is less flexible. A noindex'd iframe seems to be the best option. We already have a working proof of concept, thanks.

I thought about using googleon/googleoff tags, but apparently that's only for Google Search Appliance, and not traditional google search/index: https://webmasters.stackexchange.com/questions/54735/can-you-use-googleon-and-googleoff-comments-to-prevent-googlebot-from-indexing-p

We have an interesting design element we might try on our home page. Here's a mockup: https://codepen.io/dsbudiac/pen/Bwrgjd

I'm worried web crawlers will interpret this as keyword stuffing and affect our rankings. It features:

• Mostly transparent/hidden text
• Repeating keyword list

I could try a couple methods to skirt around crawling concerns:

1. Load keywords through an iframe
2. Make the keywords an image (would significantly increase page load)
3. Inject keywords after page load into a container w/ javascript (prob not effective as crawlers are only getting better at indexing javascript)
4. Load the keywords into an svg element
5. Load the keywords into a canvas element via javascript

I have a few questions:

1. Should I be concerned about any potential keyword stuffing / SEO issues with this design?
2. Can you comment on the effectiveness (with proof) of the above strategies?
3. Am I better off just abandoning this type of design?

In my scenario, considering I might add a parent "famous dogs" page at some point, it'd probably best to leave robots.txt alone, right?

Thanks for the response. This is what I expected.

I swear I read somewhere that Google may pass some form of value from a child to a parent. i.e. "/famous-dogs/lassie/" could pass some value to "/famous-dogs/", absent any links. Can't find the source, but I suppose I'm a bit worried that I'd permanently lose out on some value if the parent does not exist initially. Considering I may add a "famous dogs" parent page at some point.

Seems odd that indexers would care if a parent directory page exists or not. Is there any proof that Google will attempt crawl parent folder pages that aren't in sitemaps.xml and aren't linked to anywhere else?

Perhaps I'm slowly building out my site. Depending on the material/approach, it might make sense to release a page talking about a sub-category (lassie) before releasing content about a parent category (famous dogs). Or maybe "famous dogs" is such low search volume that it doesn't make sense to spend time creating a parent "famous dogs" page.

If I'm understanding correctly, with the above you're effectively telling me to:

1. Build a parent category page. If I don't plan on investing much time/effort into the parent page, noindex it.

2. Reorganize my site folder structure.

Neither seem like a great option.

Is there any issue with a 404'd parent folder in a URL? There's no links to the parent folder and a parent folder page never existed. For example say I have the following pages w/ content:

/famous-dogs/lassie/
/famous-dogs/snoopy/
/famous-dogs/scooby-doo/

But I never (and maybe never plan to) created a general **/famous-dogs/ **page. Sitemaps.xml does not link to it, nor does any page on my site.

Is there any concerns with doing this? Am I missing out on any sort of value that might pass to a parent folder?

@Will Thank you so much for this response. Very helpful.

"If you can't always refer to the image by its keyword-rich filename"...

If I'm already including the canonical link header on the image, and am able to serve from both /images/123456 and /images/golden-retriever (canonical), is there any benefit to referencing the canonical over the other in my image tags?

Again, you're mistaken. The Content-Type response header tells the browser what type of file the resource is (mime type). This is _completely different _from the file extension in URL paths.

In fact, on the web all the file extensions are faked through the URL path. For example, this page's URL path is:

https://moz.com/community/q/how-important-is-the-file-extension-in-the-url-for-images

It's not

https://moz.com/community/q/how-important-is-the-file-extension-in-the-url-for-images.html

How does the browser know the the page is an html doc? Because of the Content-Type response header. The faked "extension" in the URL path, is unnecessary.

You can view http response headers for any URL using this tool.

This isn't accurate. File extension (in the url path) is not the same as the **Content-Type **response header. Browsers respect the response header Content-Type over whatever extension I use in the path.

Example: try serving a file /golden-retriever.png with a content type of image/jpeg. Your browser will understand the file as a .jpg. If you attempt to save, your browser will correct to golden-retriever.jpg.

You can route URLs however you want.

Additionally, I'm not aware of any way browsers "leverage cache by content type". Browsers handle cache by the etag/expires header.

I know that descriptive image file names are important for SEO. But how important is it to include .png, .jpg, .gif (or whatever file extension) in the url path? i.e. https://example.com/images/golden-retriever vs. https://example.com/images/golden-retriever.jpg

Furthermore, since you can set the filename in the Content-Disposition response header, is there any need to include the descriptive filename in the URL path?

Since I'm pulling most of our images from a database, it'd be much simpler to not care about simulating a filename, and just reference an image id in my templates.

Example:

1. Browser requests GET /images/123456
2. Server responds with image setting both Content-Disposition, and Link (canonical) headers

Content-Disposition: inline; filename="golden-retriever"
Link: <https: 123456="" example.com="" images="">; rel="canonical"</https:>

Thanks for the response. What exactly makes you think this strategy would affect the speed at which google indexes the new domain?

Thanks, this is helpful. To answer the first question, do you think it's likely that the quantity/proportion of these lower quality pages are affecting our domain authority? Thus affecting the abiility of our high-quality content to rank better?

Thanks. That video is definitely useful. Mostly stuff I already am aware of, but definitely a good refresher

I'm more concerned if a slow/partial transition of indexed pages to the new domain will have any aggregate negative affect over transitioning everything all at once.

Side note: our ppc landing pages are noindex'd because they're hyper customized for the keyword, and hyper optimized for conversion. They're basically include just a request form... only supporting content is to improve conversion rates. Which is often at odds with a page optimized for organic rankings.

We're in the initial stages of planning a domain transition / rebrand.

We're considering 301'ing our low and high(er) quality content split to two different domains. One for the low quality, one for our high. Best practices normally tell you to not split your content between between multiple domains. However, what if the majority of pages on your site are thin/outdated, and attract low volume/long tail? Does it make sense to bring that low quality/volume content over the new domain, when you know you'll never have the resources (nor would it make sense to) mass improve the quality of these pages? I'm concerned the quality of these pages are affecting our overall domain authority.

Some background on our site/business:

• Current site has 15,000+ pages.
• 98% of our site is a product directory of professional/enterprise business management software.
• While a small handful of our product pages have quality original long form content (maybe 50-100), most of the product pages are a combination of: thin, outdated, overly sales-y content provided directly from product developers, and/or catch only very low-volume/long tail organic traffic.
• 95% of our pages attract fewer than 20 visits/mo, 90% of our pages attract fewer than 10 visits/mo.
• We have a small business of about 10 employees. Most of which don't maintain our site.

It's unrealistic for us to genuinely improve the quality of that many pages. Nor does it make sense to improve most of these pages, as they'll attract only very low volume keywords.

Individually these low quality pages don't bring in many customers, but on aggregate they do. 70% of our organic conversions come from pages with less than 20 visits/mo.

A few questions:

1. Is this content negatively affecting our domain authority in any way? While I don't believe we've been hit with a penalty, Google knows that on average our pages aren't very helpful to many users, and I'm concerned that affects our ability to rank with pages that matter. None of the content was mass produced in any form of scraping efforts or anything nefarious like that.
2. Would there be any negative/positive affect to offloading these low quality/volume pages to a different domain during the rebrand?

We're planning a domain name (rebrand) transition, and considering our options.

We rely heavily on paid traffic. To reduce risk, we’re considering moving AdWords and Bing Ads over campaign-by-campaign to the new domain first, while organic traffic continues to direct to the old domain. Each of our ad groups has a custom, noindex’d landing page. In order to serve paid traffic, we’d at minimum need a front page, and likely a privacy policy page in addition. Here’s a rough outline of what I think a transition like this might look like:

1. Launch new domain with a simple front page, and privacy policy.
2. Move over ppc landing pages on the new domain (noindex'd, robots.txt)
3. Create new ads in existing ad groups directing to the new domain.
4. Monitor ad groups for some time period to verify sustainability.
5. Once we're satisfied with ppc performance, and planned the rest of the organic page migrations, 301 redirect everything to the new domain.

Is there any problems or things we should be concerned about with this approach? I'd think it should be fine, but I've been bitten enough from large-scale redirects in the past, that I know I should be nervous.

I have two sites: Site A, and Site B. Both sites are hosted on the same IP address, and server using IIS 7.5. Site B has an SSL cert, and Site A does not. It has recently been brought to my attention that when requesting the HTTPS version of Site A (the site w/o an SSL cert), IIS will serve Site B...

Our server has been configured this way for roughly a year. We don't do any promotion of Site A using HTTPS URLs, though I suppose somebody could accidentally link to or type in HTTPS and get the wrong website.

Until we can upgrade to IIS8 / Windows Server 2012 to support SNI, it seems I have two reasonable options:

1. Move Site B over to its own dedicated IP, and let HTTPS requests for Site A 404.
2. Get another certificate for Site A, and have it's HTTPS version 301 redirect to HTTP/non-ssl.

#1 seems preferable, as we don't really need an SSL cert for Site A, and HTTPS doesn't really have any SEO benefits over HTTP/non-ssl.

However, I'm concerned if we've done any SEO damage to Site A by letting our configuration sit this way for so long. I could see Googlebot trying https versions of websites to test if they exist, even if there aren't any ssl/https links for the given domain in the wild... In which case, option #2 would seem to mostly reverse any damage done (if any). Though Site A seems to be indexed fine. No concerns other than my gut.

Does anybody have any recommendations? Thanks!

A small blog owner has asked if they can word-for-word republish one of our blog articles on their own blog. I'm not sure how to respond.

We're don't do any outreach to submit or duplicate our articles throughout the web... so this isn't something being done in mass. And this could be a great signal to Google that somebody else is vouching for the quality of our article, right?

However, I'm a bit concerned about word-for-word duplicating. Normally, if somebody is interested in re-publishing, both the re-publisher and our website would get more value out of it if they re-publisher added some form of commentary or extra value to our post when citing it, right?

This small blog just started releasing a segment in which they've titled "guest blog Thursday". And given the recent concerns with guest blogging (even though I'm not sure this is the classical sense of guest blogging), I'm even more concerned.

Any ideas on how I should respond?