301 redirect SmugMug domains to custom domains

juanheredia

Letting us 301 redirect from the SmugMug domain to our custom domain would help with SEO.

I think this is very important not only for SEO, but for bookmarking and searching.

I you are interested you vote here http://feedback.smugmug.com/forums/17723-smugmug/suggestions/1958095-301-redirect-smugmug-domains-to-custom-domains

jasonscottphoto

Didn't this used to be the case? Now I see when I type in my smugmug address, it doesn't redirect to my custom URL. I swear it used to...

denisegoldberg

I actually don't want my smug URL to redirect to my custom URL. I'd prefer to have both. That way if my domain provider is not available for some reason my site can still be accessed.

--- Denise

juanheredia

jasonscottphoto wrote: »

Didn't this used to be the case? Now I see when I type in my smugmug address, it doesn't redirect to my custom URL. I swear it used to...

Yes, it used to work before. That's why I'm asking this feature to be implemented.

Sent from my S3 using Tapatalk 4

juanheredia

denisegoldberg wrote: »

I actually don't want my smug URL to redirect to my custom URL. I'd prefer to have both. That way if my domain provider is not available for some reason my site can still be accessed.

--- Denise

Yes, I understand what you mean. But for SEO and statistics, is better to have just one. This kind of redirect tells search engines that the sites must be treated as one.

Sent from my S3 using Tapatalk 4

paulbrock

redirect ***.smugmug.com to custom domain
Another javascript functionality request.

Previously we were able to ensure that if someone happened to land on e.g. paulbrock.smugmug.com, it would redirect to www.paulbrockphotography.co.uk through the use of javascript. (or perhaps a Smugmug implemented 301 redirect)

This no longer happens, please add it to the list.

Thanks.

juanheredia

Yes, please We need that feature back.
I used to have this JS in order to redirect to my custom domain.

// For Canonical - Only work on client.
var myhost = 'jchmportafolio.infoinnova.net';
var originalHost = location.host.toLowerCase();
if (originalHost != myhost) window.location = window.location.href.replace(originalHost, myhost);

paulbrock

according to Baldy, this should be happening right now...

Baldy wrote: »

It's a longer story and deserves a longer response, but we do a 301 redirect, which is the one that lets Google transfer SEO to the new domain. I'll respond with more when I get a chance.

Changing it to a bug.

pbandj

Hmmm...I don't think I used javascript to do this; I thought it used to happen automatically in legacy smugmug.

rich56k

pbandj wrote: »

Hmmm...I don't think I used javascript to do this; I thought it used to happen automatically in legacy smugmug.

Same here, mines been redirecting for like 6-7 years now without issue.

I don't recall ever doing anything other than setting it up with GoDaddy after I got the domain hooked up...

juanheredia

rich56k wrote: »

Same here, mines been redirecting for like 6-7 years now without issue.

I don't recall ever doing anything other than setting it up with GoDaddy after I got the domain hooked up...

Nope, we always had two URLs.

Sent from my S3 using Tapatalk 4

WinsomeWorks

rich56k wrote: »

Same here, mines been redirecting for like 6-7 years now without issue.

I don't recall ever doing anything other than setting it up with GoDaddy after I got the domain hooked up...

You had to do something. It never re-directed on its own. You either used Javascript or set it up through your domain/s. You can still check this on my site. I haven't built in a re-direct, and I'm still on Legacy.

paulbrock

I had a look through my old code, and couldn't see anything for redirects, other than the vanity url stuff.

southeasternphotography

+1 if this is not being redirected - Baldy?

WinsomeWorks

southeasternphotography wrote: »

+1 if this is not being redirected - Baldy?

Just to be clear though-- not everyone wants a re-direct. So it shouldn't be a default; it should be an option, such as we were able to do with Javascript if we wanted.

Baldy

WinsomeWorks wrote: »

Just to be clear though-- not everyone wants a re-direct. So it shouldn't be a default; it should be an option, such as we were able to do with Javascript if we wanted.

Okay, I have been digging into this issue and want to understand why some people don't want nickname.smugmug.com to redirect to their custom domain.

As far as google knows, your domain is your custom domain. For example,



The reason is that in your site map, we direct Google to your custom domain.

We are trying to remember why we stopped (long ago) doing 301 redirects on your smugmug home page if you typed in nickname.smugmug.com and we think it's because we had to provide a way for people who misconfigured their domains at their registrars to get to smugmug without 404ing.

The scenario was you enter into your settings at smugmug your domain, so we think we should point to it and have no way of knowing otherwise. But something fubars at your registrar and all your visitors start getting 404s because we're redirecting to a broken domain. You try to login to change the setting in your control panel but you can't because we're redirecting to a broken domain.

We could easily do a 301 on your home page and I know some people will believe that helps SEO, but I'd like to know more about why some people don't want it, and think through what to do about people when something goes wrong with their custom domains.

paulbrock

Thanks for the info, and the free extra of seeing my rich snippets/author tag is showing up in results. :-) Yeah, not a biggie for me, most people would never see Paulbrock.SmugMug.com anyway but given the choice, I would turn on redirection. Custom domain looks more professional

Sent from my PadFone 2 using Tapatalk 4

Baldy

jfriend wrote: »

One possibility is that you could skip the auto-redirect if the site owner was logged in. Then the work-around when the custom domain wasn't working would be to go to www.smugmug.com and log in. Then go to username.smugmug.com (it would not redirect because you're logged in) and you could then fix your custom domain configuration.

This makes a lot of sense but if I remember right, I think that's what we were doing. The problem was we didn't solve how to let the user know they could login at www, so there was panic and posts to the social world about us being broken and down as soon as they saw their site 404ing.

renstar

Baldy wrote: »

This makes a lot of sense but if I remember right, I think that's what we were doing. The problem was we didn't solve how to let the user know they could login at www, so there was panic and posts to the social world about us being broken and down as soon as they saw their site 404ing.

So redirect pages that are not in the smugmug namespace (which dovetails with the lower case issue), but don't redirect example.smugmug.com/login? It could still be a problem if people don't know about /login, /organize, etc, though.

jfriend

Baldy wrote: »

This makes a lot of sense but if I remember right, I think that's what we were doing. The problem was we didn't solve how to let the user know they could login at www, so there was panic and posts to the social world about us being broken and down as soon as they saw their site 404ing.

Is it more important to "do the right thing" when the custom domain is working properly? or optimize things for when their custom domain is broken? Hopefully, the usual case is the custom domain is working. You may have to decide which gets the primary optimization and which gets the best you can do after you've optimized the other. I know which I'd pick.

As a tangential feature idea, if you're being accused of being down when people mess up their custom domains or forget to renew them, you could go proactive on that front and start a monitoring service where you ping your customer's custom domains a few times a day and proactively alert them when there's a problem with the custom domain access they have configured, but no problem with the nickname.smugmug.com access. Then, they might hear about it from you via email first before their own viewers tell them about it, thus avoiding the thought that SM is down.

Baldy

jfriend wrote: »

Is it more important to "do the right thing" when the custom domain is working properly? or optimize things for when their custom domain is broken? Hopefully, the usual case is the custom domain is working. You may have to decide which gets the primary optimization and which gets the best you can do after you've optimized the other. I know which I'd pick.

As a tangential feature idea, if you're being accused of being down when people mess up their custom domains or forget to renew them, you could go proactive on that front and start a monitoring service where you ping your customer's custom domains a few times a day and proactively alert them when there's a problem with the custom domain access they have configured, but no problem with the nickname.smugmug.com access. Then, they might hear about it from you via email first before their own viewers tell them about it, thus avoiding the thought that SM is down.

I alluded elsewhere that it's inevitable that we have to do something about this anyway, because we'll have to have logged-in users do all their browsing on https. What it means is they won't be able to browse their custom domains logged in. It's one of those things we don't get many requests for (https browsing). However, most people would want it if they knew a lot about security, but there will be some very bad consequences to the user experience.

I'm still very interested to hear from people like Denise Goldberg, who posted that they don't want us to redirect their domains. http://www.dgrin.com/showthread.php?t=237875

In terms of monitoring the custom domain to see if it's broken, there are several use cases that would be easy to detect (the domain 404s) but many that are hard. For example, suppose they configure their CNAME to smugmug.com and make an entry in SmugMug's settings panel. Later they change the CNAME to wordpress but don't think to change the settings in their SmugMug setting panel.

If we have 100,000 users with custom domains, it's quite a thing to diagnose. Breakages are constantly coming and going from outages at registrars to you name it. Trying to diagnose the outages and knowing what to do about them is quite a thing.

Baldy

We seem to have two threads going on this. Can youz join this one?

http://www.dgrin.com/showthread.php?p=1905879

mbonocore

Baldy, I merged the threads.

jfriend

Baldy wrote: »

I alluded elsewhere that it's inevitable that we have to do something about this anyway, because we'll have to have logged-in users do all their browsing on https. What it means is they won't be able to browse their custom domains logged in. It's one of those things we don't get many requests for (https browsing). However, most people would want it if they knew a lot about security, but there will be some very bad consequences to the user experience.

I'm still very interested to hear from people like Denise Goldberg, who posted that they don't want us to redirect their domains. http://www.dgrin.com/showthread.php?t=237875

In terms of monitoring the custom domain to see if it's broken, there are several use cases that would be easy to detect (the domain 404s) but many that are hard. For example, suppose they configure their CNAME to smugmug.com and make an entry in SmugMug's settings panel. Later they change the CNAME to wordpress but don't think to change the settings in their SmugMug setting panel.

If we have 100,000 users with custom domains, it's quite a thing to diagnose. Breakages are constantly coming and going from outages at registrars to you name it. Trying to diagnose the outages and knowing what to do about them is quite a thing.

I can't imagine it's all that hard to look up the DNS entry for the custom domain that a SM account is configured for and see if it's still pointing at the right SM IP address and, if not and that condition persists for some short time, then notify the SM user by email that their custom domain does not appear to be properly configured.

But if that's too much work for you or not something you want to do, then I guess you can just live with these false reports about SM being down. You were complaining about the false down reports so I suggested something proactive you could do about it. Anyway, I'm not going to argue with you. It was an idea I shared that apparently you have rejected. I think you've made it more complicated than it needs to be to be useful, but I was just trying to be helpful.

GRBlizz

Baldy wrote: »

I alluded elsewhere that it's inevitable that we have to do something about this anyway, because we'll have to have logged-in users do all their browsing on https. What it means is they won't be able to browse their custom domains logged in. It's one of those things we don't get many requests for (https browsing). However, most people would want it if they knew a lot about security, but there will be some very bad consequences to the user experience.

I'm still very interested to hear from people like Denise Goldberg, who posted that they don't want us to redirect their domains. http://www.dgrin.com/showthread.php?t=237875

In terms of monitoring the custom domain to see if it's broken, there are several use cases that would be easy to detect (the domain 404s) but many that are hard. For example, suppose they configure their CNAME to smugmug.com and make an entry in SmugMug's settings panel. Later they change the CNAME to wordpress but don't think to change the settings in their SmugMug setting panel.

If we have 100,000 users with custom domains, it's quite a thing to diagnose. Breakages are constantly coming and going from outages at registrars to you name it. Trying to diagnose the outages and knowing what to do about them is quite a thing.

Baldy, is this issue related to the issue that any reorganization in new SM results in broken links?

Example from my personal page: I have a gallery that lives in a Top-Level Folder (Category, in Legacy nomenclature) called Family.

http://sunnyshots.smugmug.com/Family/Blizzards-Birthday-Pictures

If I decided to collect all pages for my pets into a new sub-category/folder under Family called Pets, and use the organizer to move this album to that sub-category/folder.

Its URL is now: http://sunnyshots.smugmug.com/Family/Pets/Blizzards-Birthday-Pictures

If I'd done this in Legacy, someone clicking on http://sunnyshots.smugmug.com/Family/Blizzards-Birthday-Pictures in a blog, Facebook page, or email would have the url resolve to its new URL: http://sunnyshots.smugmug.com/Family/Pets/Blizzards-Birthday-Pictures

In New SM, the old URL goes to a Page not Found.

For my family album, it's kinda annoying. For my work site, where we have hundreds of blog posts with links to SM galleries, it's pretty close to a disaster.

Not being super-technical, I think this is related to the 301 issue, but I'm not sure. Can you advise if this is something you're working on? Is it a bug that needs fixing, or a feature that was left out of this redesign.

Baldy

GRBlizz wrote: »

Baldy, is this issue related to the issue that any reorganization in new SM results in broken links?

Example from my personal page: I have a gallery that lives in a Top-Level Folder (Category, in Legacy nomenclature) called Family.

http://sunnyshots.smugmug.com/Family/Blizzards-Birthday-Pictures

If I decided to collect all pages for my pets into a new sub-category/folder under Family called Pets, and use the organizer to move this album to that sub-category/folder.

Its URL is now: http://sunnyshots.smugmug.com/Family/Pets/Blizzards-Birthday-Pictures

If I'd done this in Legacy, someone clicking on http://sunnyshots.smugmug.com/Family/Blizzards-Birthday-Pictures in a blog, Facebook page, or email would have the url resolve to its new URL: http://sunnyshots.smugmug.com/Family/Pets/Blizzards-Birthday-Pictures

In New SM, the old URL goes to a Page not Found.

For my family album, it's kinda annoying. For my work site, where we have hundreds of blog posts with links to SM galleries, it's pretty close to a disaster.

Not being super-technical, I think this is related to the 301 issue, but I'm not sure. Can you advise if this is something you're working on? Is it a bug that needs fixing, or a feature that was left out of this redesign.

Hmmmm, GRBlizz, I'm not sure I totally understand this so I'm gonna call in some reinforcements.

The thing is your gallery links don't have the key appended to the end that uniquely identifies the gallery. If you have them, the gallery links won't break no matter how many moves you make. I can understand why you wouldn't want to include them because they complicate the URL. But without a unique identifier, it opens us up to collisions with multiple galleries of the same non-unique URL.

On legacy, we always displayed the key at the end of the URL in the browser, so when you copied and pasted the URL, the key went with it. We still do that with get a link. We did provide a NiceName function in legacy so you could give out the URL with no key and it would work, but we gave a disclaimer that if you moved the gallery, the link would break. But there wasn't as much moving in legacy before the new organizer and anyway that was probably a bad idea.

What we seem to have done with new is drop the key in the address bar of the browser and make it easy to move, exacerbating the problem.

But I am going to double-check my answer with Ryan, Evan and Mark, who should know for sure.

Baldy

jfriend wrote: »

I can't imagine it's all that hard to look up the DNS entry for the custom domain that a SM account is configured for and see if it's still pointing at the right SM IP address and, if not and that condition persists for some short time, then notify the SM user by email that their custom domain does not appear to be properly configured.

But if that's too much work for you or not something you want to do, then I guess you can just live with these false reports about SM being down. You were complaining about the false down reports so I suggested something proactive you could do about it. Anyway, I'm not going to argue with you. It was an idea I shared that apparently you have rejected. I think you've made it more complicated than it needs to be to be useful, but I was just trying to be helpful.

No worries, I didn't think of it as an argument and took it as a good suggestion to help. Honestly, we didn't have a really deep conversation on it yet, just a preliminary one. But I began to get a sinking feeling as we went through the list of possible URL configs our customers have, from cname to a name to url forwarding, and the way it often fails in some region of the world or on some ISP.

I'm no DNS monitoring expert, but the guys at Dyn suggested that if we want to get into it, to partner with someone who really knows it like InternetSeer, which is what they did.

GRBlizz

Baldy wrote: »

Hmmmm, GRBlizz, I'm not sure I totally understand this so I'm gonna call in some reinforcements.

The thing is your gallery links don't have the key appended to the end that uniquely identifies the gallery. If you have them, the gallery links won't break no matter how many moves you make. I can understand why you wouldn't want to include them because they complicate the URL. But without a unique identifier, it opens us up to collisions with multiple galleries of the same non-unique URL.

On legacy, we always displayed the key at the end of the URL in the browser, so when you copied and pasted the URL, the key went with it. We still do that with get a link. We did provide a NiceName function in legacy so you could give out the URL with no key and it would work, but we gave a disclaimer that if you moved the gallery, the link would break. But there wasn't as much moving in legacy before the new organizer and anyway that was probably a bad idea.

What we seem to have done with new is drop the key in the address bar of the browser and make it easy to move, exacerbating the problem.

But I am going to double-check my answer with Ryan, Evan and Mark, who should know for sure.

Thank you, Baldy! I have found, through experimentation, that the links I generated with the "shorten this link" function in Legacy do still find the desired gallery, even after all the moving around.

I haven't found how to use that function in the new SM. I think you still have it, since I followed a smu.gs link on Facebook to your most recent blog post. But how can I use it?

I did try using get a link in New SM, and t did not generate the key, just the same URL that was in the browser. WHen I did an experiment of moving the gallery to a subfolder, the link broke.

I'd appreciate your looking into this.

pbandj

Baldy wrote: »

On legacy, we always displayed the key at the end of the URL in the browser, so when you copied and pasted the URL, the key went with it. We still do that with get a link.

That might have been your intention, but as GRBlizz pointed out, this is broken in new smugmug. Get a link (The Gallery Link) does not have the album key on it, the lightbox version does not have an album key on it, and the slideshow version has an album key, but the link goes to a legacy version of the slideshow. See the bug report I filed here for more details: http://www.dgrin.com/showthread.php?t=240063

GRBlizz

pbandj wrote: »

That might have been your intention, but as GRBlizz pointed out, this is broken in new smugmug. Get a link (The Gallery Link) does not have the album key on it, the lightbox version does not have an album key on it, and the slideshow version has an album key, but the link goes to a legacy version of the slideshow. See the bug report I filed here for more details: http://www.dgrin.com/showthread.php?t=240063

I think I understand the issue thanks to some help from Hero Wendy and a little experimenting.

The problem comes from the fact that the Collage style (both L and P) perform differently from the way that SmugMug and Journal styles perform (Legacy and new). Along with half the universe, I have embraced those cool new styles, hence the problem.

In the SmugMug and journal style, the URL "galleryname/imagekey" returns the gallery page of the image associated with the key. This was the case with Legacy, and is also true in New. So if you're using one of those styles and make sure to capture the key when you share the URL, you're fine. A link to an image on the main gallery page has the same function as a link to the gallery.

The problem is, in Collage styles (and Thumbnails,) the URL "galleryname/imagekey" returns the lightbox view for that image, after briefly flashing on the gallery page. Users have to figure out that they can close the lightbox and see the full gallery.


Here's an illustration, using two galleries that have shortlinks to each other.

http://pictures.mtbethel.org/Ministry/Childrens/2012/Ornament-Making-on-Santa/i-6gqzbgb - SmugMug style gallery, link goes to gallery page. Note that the URL of the lightbox associated with each image is galleryname/imagekey/A

http://pictures.mtbethel.org/Ministry/Childrens/2012/Santa-Pictures-2012/i-p8j5bQv - Landscape Collage style gallery, link goes briefly to gallery page and then pops to lightbox page for that image. If you close the lightbox view and click on an image from the gallery page to go back to lightbox view, the resulting URL is galleryname/imagekey/A

I think Collage styles should function the same as the other styles, ie, galleryname/imagekey should return the gallery page containing the image, and galleryname/imagekey/A should return the page containing the lightbox image in all styles.

If not, then there needs to be a permanent "gallery key", just as each image has a key.

Update: Heroes just responded again (response time shortening quite a bit, yay!) and told me that there is a gallery key, and it's exposed as the "buy" link. Add that to the end of your gallery URL, and you can share with ease - either directly or with a link shortener. Feature request is in to make this gallery link part of the URL and Get a Link.

GRBlizz

pbandj wrote: »

That might have been your intention, but as GRBlizz pointed out, this is broken in new smugmug. Get a link (The Gallery Link) does not have the album key on it, the lightbox version does not have an album key on it, and the slideshow version has an album key, but the link goes to a legacy version of the slideshow. See the bug report I filed here for more details: http://www.dgrin.com/showthread.php?t=240063

Thank you for sharing that link. Please read my reply below, and see if you agree that I've identified the issue. I'll also post it on your thread. I now see that it does not relate to the topic of this thread, and I]m fine with having it moved.