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.

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