META and bookmarking

# Andy Valencia (a month ago)

I'm in the throes of a media startup, and ran into one of those issues which runs surprisingly deep.

Like many sites, my front page is a portal which sends the user on to the actual source of content for that user on that day. In my case, it's a particular media server (after choosing based on current load) plus a session token in the URL. I've been researching this, other cases are where the redirect URL reflects the current day/edition/release.

The problem is if you like the site and decide to bookmark it-- including a home screen bookmark on mobile. You're off on a transient URL, which is not the right one to bookmark. On a desktop browser you can go into the extended dialog and hand-modify the URL (some users could, others not so much). On mobile, it can be difficult--on some devices even impossible.

I'm wondering if a <meta bookmark="url"> tag would be appropriate? This

would let a page which knows it's not a good long-term bookmark target to suggest a better URL to use. In its absence, of course the current URL is used.

For security, you could claim that anywhere Bad it would send you is a place the current page could have already sent you. If the page was served under HTTP, I guess a lame ISP could insert themselves. Possibly recommend ignoring the value from non-HTTPS pages? That certainly aligns with Mozilla's stated intentions for future features.

Thanks, Andy Valencia

Contact us to advertise here
# Roger H├ągensen (a month ago)

Add a link in the header and use rel=canonical which tells the browser that the link is the correct url.

If all modern browsers actually uses the canonical url when you bookmark a page I have no idea, ideally they should though. File a bug report with the browsers if they don't.

Do note that search engines consider a slightly different meaning for rel=canonical though.

I'm curious though why you do not want the users to bookmark the subpage but the portal page instead.

Maybe rethink the design so that the portal (aka landing page) actually does not auto redirect. Present a clickable image (href + image) that the user can click or tap on. That way they can bookmark the portal page before clicking onwards.

Also make sure the users can click a back button on the subpage to go back to the portal page (call it Index or Home or Portal or something).

If you do not control these subpages yourself (they are somebody elses sites) then no browser devs will ever let you hijack the bookmarking of those. In this case you have a Directory/Indexing/Portal site and the only solution is to wait for the user to click before you send them to the foreign site. That way they can bookmark the portal site.

If the destination url contains a referral id of sorts then it's the destination site's responsibility to remove it if it's single use.

I dare say that in the "majority" of cases if you are unable to do something on the web today it's because you are doing it the wrong way. I say "majority" because there are bound to be cases where this is not true. But in your case you might need to re-evaluate the way you do the redirect.

Now, I haven't seen your portal site so I'm just making assumptions here so I apologise beforehand in case my assumptions are way off.


# Andy Valencia (18 hours ago)

Thank you very much for pointing me at the right bits of existing standards.

Matthew Wronka's reference of a "canonical relationship" and RFC6596 is very much on target. rel=canonical should do as much as I could hope for in any case.

I of course considered an initial landing page, but UX pushes strongly where the 99.999% case is not the one which should require the extra click. I'll certainly have the canonical link specified, and hope for the best. Perhaps even, as you say, submit a ticket to a browser or two.

Thanks again, Andy Valencia

Want more features?

Request early access to our private beta of readable email premium.