This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the shebang/hashbang (#!) in Facebook and new Twitter URLs for?
I noticed that some popular sites started switching to a new URL (convention?), in which a URI segment is no longer prefixed by / but rather by #!/.
For example, if you type into Twitter http://twitter.com/stackoverflow, it will immediately redirect to http://twitter.com/#!/stackoverflow.
Had I seen this on Twitter only, I wouldn't have thought twice about this, but now I am seeing this in other sites.
Is this a new convention for URL redirection? Where can I learn more about this?
It was started by Google ( http://code.google.com/web/ajaxcrawling/ )
If you're running an AJAX application
with content that you'd like to appear
in search results, we have a new
process that, when implemented, can
help Google (and potentially other
search engines) crawl and index your
content. Historically, AJAX
applications have been difficult for
search engines to process because AJAX
content is produced dynamically by the
browser and thus not visible to
crawlers. While there are existing
methods for dealing with this problem,
they involve regular manual
maintenance to keep the content
up-to-date.
Look at this answer here:
What's the shebang/hashbang (#!) in Facebook and new Twitter URLs for?
The opinion on using this is split - Gawker had major issues after taking this up : http://www.webmonkey.com/2011/02/gawker-learns-the-hard-way-why-hash-bang-urls-are-evil/
It's how Google should index the page when dealing with AJAX
Related
I am writing a complex AJAX application at the moment and the entire site has clean URLs. At the moment PHP creates the basic layout for each page however I don't want to have to navigate away from each page when the user clicks on a link, and I don't want to have a hash in the URL because it won't fit with the rest of the site. I know that this has cropped up loads before on the site and it seems to be quite commonly asked but I was wondering if there was a neat HTML5 way of just appearing to change the URL in the address bar even if it technically remains on the same page.
You can do it with history.pushState, but only in browsers that support it. Just try the following line in your browsers JavaScript-Console.
history.pushState({},"URL Rewrite Example","https://stackoverflow.com/example")
More on that in The pushState() method (Mozilla Developer)
Similar question How do I, with JavaScript, change the URL in the browser without loading the new page?
As others have stated, HTML5's history.pushstate is the way to go. Try browsing a repo on github to see it in action (https://github.com/visionmedia/express).
Trouble is the only version of IE that supports history.pushstate is IE10, which kinda sucks.
Plenty of sites use hashbang #! URL's such as Twitter (e.g. https://twitter.com/#!/Sironfoot ). The hashbang is a URL pattern agreed on by search engines so that they can still trawl and index a heavily Ajax powered website (more info here http://code.google.com/web/ajaxcrawling/docs/specification.html), so you could go that route.
The only other approach is to use history.pushstate for browsers that support it, and fall back to full-page refreshes for non-supporting browsers.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the shebang/hashbang (#!) in Facebook and new Twitter URLs for?
I see twitter's url is this type:
twitter/#!/username
I known that twitter's front page uses ruby on rails framework, but "#!" is not the suggest type in RoR restful routes. So why twitter uses this strange url type? Is there any special reason?
It's a hashbang URL. In the days before HTML5 JavaScript URL rewriting, there was no way to rewrite stuff in the address bar, except for the hash symbol. Natively, the hash symbol in a link points to the id of some element on the webpage. This is overridden in JavaScript to perform other actions.
It's really weird that Twitter is using it, especially since there are libraries that failover to using hashbang but use the new history.pushState function when it's available.
Twitter uses AJAX a lot on their pages. You almost never see a reloa of the whole page. By using those anchor links they avoid reloading the page but still give you a chance to store the current state of the page as a favorite or use the back button of your browser
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
I have a problem concerning Google cache my old content URLs while I created a new website
I have an old website where the old webpages are dead now and created a new website with new webpages.
Because I have old content so when people search on Google for old content the old URLs appear in the search results (as it was cached) instead of the new ones which should be appearing (but not indexed yet), this is because the old content is already indexed by Google and the new ones are not indexed yet.
While when people search of new content the new URLs appear. So for the new content there is no problem, but the problem I have is with the old content.
For that reason above, now I created a new pages with the old URL names to redirect to the new page with the new URL when people search for old content.
My question is what I did to solve this will help the old URLs to disappear from Google cached pages and start to index the OLD content with new URLs instead or should I keep with page not found?
Here's an example of the case I have:
When I search for old content this URL appear in search results --
www.example.com/Sectionnewsdetail.aspx?id=10132
which is deleted and land on page not found
So I created a webpage with the old name
Sectionnewsdetail.aspx to redirect to the new content page --
http://www.example.com/Content/SectionNews.aspx?NewsID=13855
whenever any one click on the old URL on Google my solution redirects him to the new page
So which case will help Google cache forget the old URLs and index the new URLs.
Keeping page not found or the solution I did as explained above?
Try submitting your site again. But It could still take a week or two.
The easiest way could be adding the cross-domain rel="canonical" link element in your old website. Google Tutorial
There are situations where it's not easily possible to set up
redirects. This could be the case when you need to move your website
from a server that does not feature server-side redirects. In a
situation like this, you can use the rel="canonical" link element
across domains to specify the exact URL of whichever domain is
preferred for indexing. While the rel="canonical" link element is seen
as a hint and not an absolute directive, we do try to follow it where
possible.
Basically I want to know how many people have tweeted a link to a url, but since there are dozens of link shortener out there I don't see any way to do this without having access to all of their url maps. I found a previous question here but it was over a year old and didn't have any new answers.
So #1, does anyone know of a service/API for doing this?
And #2, can anyone think of a way to accomplish this task other than submitting the long url in question to all the popular link shortening sites?
ps- I'm also open to comments about why this is impossible or impractical.
You could perform a Google search (or the equivalent via API) for any pages that link to your page. This is done with the link: keyword. So if you're trying to figure out how many people link to www.example.com (regardless of whether it's through a link shortner URL), then you would just do a Google search for link:www.example.com.
e.g.: http://www.google.com/search?q=link:www.example.com
Note that this will only find pages that have been indexed, so pages that haven't been crawled, or pages that get crawled infrequently, will not show up in the results until a later date (if at all).
Since all sites have different algorithms for shortening the URLs, and these are different sites that most likely do not share their data with each other, how can you hope to find all of them in a single or small number of queries?
All you can do is brute-force it, and even then this might not be any good if a site is content to create a new value for the same long-form URL (especially if you send a different long-form URL that maps to the same place, like http://www.stackoverflow.com/ rather than http://stackoverflow.com/).
In order to really get this to work, there would have to be a site that ALREADY automatically collects all of this information from every site, which the URL shortening sites voluntarily call. And even if you wrote such a site, that doesn't account for the URL-shortening sites already out there who already have data!
In short, I do not see how this is remotely possible, unless I'm wrong about there being such a database somewhere out there.
So months after asking this question I came across a solution to a similar question, that is how to tell how many times a link has been shared on facebook. The solution, via a simple new API call:
http://graph.facebook.com/http://stackoverflow.com
returns the following json data:
{
"id": "http://stackoverflow.com",
"shares": 1627
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In short, why use something like http://stackoverflow.com/badges/6/supporter instead of something "simpler" (and subjectively, at that) like http://stackoverflow.com/badges/6/.
Even on my own site I've just been using /post/6/ to reference posts (by IDs, even though I still store a slug.) Instead of /post/6/small-rant-on-urls, and in some cases, they can get even more absurd, much more so than is really necessary.
Search Engine Optimisation would be one, as well as making the URL more readable to humans. Search engines generally like your URL, Title and H2 to contain the "topic" of the page.
If you have both in there then you can manually type /ID and get automagically taken to the "flowery" URL with rewriting.. saves your fingers a bit :)
Because you can potentially end up with duplicates if you're not careful. I imagine stack overflow added the ID because there was a high potential for duplicates given the volume of posts created.
Other systems may choose not to use the ID in the URL - for example, a blogging system probably would not need to.
It's a better idea if you have user generated content that results in a new URL created to include a post ID. If the only way new URL's can be created is through administrator type access, you can probably do without it as long as you check for duplicates.
Adding the slug in all links to the content helps with search engines, because search engines will generally use words in the URL itself to help index content.
The reason for including the id in the url is that it makes it easier behind the scenes to retrieve the correct article from the database, as a lookup can be performed on the ID rather than the article's title.
The reason for including the full title of the article, is that Google gives heaps of bonus points for search terms that are matched in the filename.
URL is part of the Web user interface.
There is an eyetracking study of search engine use that found that people spend 24% of their gaze time looking at the URLs in the search results.
Searchers are particularly interested in the URL when they are assessing credibility and usefulness of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user's question, they are more likely to click.
#Greg Hewgill
Adding the slug in all links to the content helps with search engines, because search engines will generally use words in the URL itself to help index content.
I should have clarified a bit: I meant URLs that have both an id and slug in them. I just don't see the point in having something like /post/1/la-la-la-la-text-hahahaha vs /post/1/ or /post/la-la-la-la-text-hahahaha, since the first one would work without the extranous text at the end.
It could be that is faster to get the post in a blog by the id than by the slug, so put the id for the SQL query and the slug for the search engines (SEO).
https://stackoverflow.com/users/58163/movaxes65675
I like the /post/la-la-la-la-text-hahahaha type, i can remember the url, know what the title of the post is (before actually loading the site). Don't like much the /post/1/ it means nothing to me but post #1 (bad for marketing?)
edit: id also helps to avoid duplicates as andybaird pointed
Well, firstly it should be pointed out that the "Web 2.0 style URLs" are actually part of something called REST. Those URLs are sometimes called RESTful URLs. The claimed benefits are:
Provides improved response time and reduced server load due to its support
for the caching of representations;
Improves server scalability by reducing the need to maintain session
state. This means that different
servers can be used to handle
different requests in a session;
Requires less client-side software to be written than other approaches,
because a single browser can access
any application and any resource;
Depends less on vendor software and mechanisms which layer additional
messaging frameworks on top of HTTP;
Provides equivalent functionality when compared to alternative
approaches to communication;
Does not require a separate resource discovery mechanism, due to
the use of hyperlinks in
representations;
Provides better long-term compatibility and evolvability
characteristics than RPC. This is due
to:
The capability of document types such as HTML to evolve without
breaking backwards- or
forwards-compatibility; and
The ability of resources to add support for new content types as they
are defined without dropping or
reducing support for older content
types.