I think this could be a common question, but I didn't find my answer, so that's the reason I am asking this. I am sorry if I am being repetitive.
I have a page with some categories. And each category has some category as its children. And, the user can click in this categories and the $scope.categories will change with those children, until we have no children anymore.
But, when the user clicks in a category to show its children, I want to change the URL, to make a permalink for the visible category at the time.
I tried to use $location, but $location does not change my absURL, it just set a anchor at the end of the URL, like '/path#category_slug'. I want to change to '/path/category_slug'. The reason is that I want to index those URLs in search engines.
So, if the user entry in '/path/category_slug', I will change $scope.categories based in the category_slug.
My question is, what is the best options to do this?
If you are using AngularJS it is unlikely that Google or other search engines will understand little of your site content. Th e problem is greater than just navigation! See the following question:
How do search engines deal with AngularJS applications?
If you are concerned about search engines, you are going to have to create a more traditional page-based site, using angular for small amounts of interactivity.
If you switch your AngularJS app to HTML5 mode, you will no longer have those # symbols in urls.
In your app.js file, set html5 mode to true:
$locationProvider.html5Mode(true);
But be careful, it's not so simple. You then have to configure your server to rewrite all requests. We call that "url rewriting" and there are many ways to do it depending on which server you use.
Related
Why is it a bad idea to have a ID in the URL in terms of SEO? How does this URL
http://example.com/user/1234 hurt SEO?
Can someone give me a practical example where search engine rankings are worse?
The reason people are saying that {ID} in the URL is bad is due to the way search engine algorithms work. When a search term is located in the actual URL, it is weighted much more heavily than the content of the page, etc.
For example:
<!-- http://example.com/blog/57 -->
<html><head><title>An article on search engine optimization</title>...
vs
<!-- http://example.com/blog/an-article-on-search-engine-optimization -->
<html><head><title>An article on search engine optimization</title>...
If you do a search in Google for "Search Engine Optimization" the second page, the one with the slug in the url will weight as a better result than the one with only the id.
You can deal with this in the same way that stack overflow deals with this issue:
http://stackoverflow.com/questions/{id}/{slug}
http://stackoverflow.com/questions/910683/why-is-id-in-the-url-a-bad-idea
The combined id and slug format really helps you achieve the best of both worlds. You get the ease of programming by retrieving records by {id}, but you also retain the optimized search URL because of the {slug}.
It does have an effect of the click-through rate.
The url is presented in green below the search result - so if it contains relevant words the user might click your site and not another site.
Which would you rather click:
www.test.com/page.php?u=85583
OR
www.test.com/Solution-to-your-problem.php
As commented this effect may be achieved even with urls including an id.
In the olden days it search engines treated words in url with much respect and gave those pages extra credit and higher ranking. This effect has almost vanished. We are left with two other effects of readable urls:
Clickthrough
Linkbuilding: Easier for a human to copy such a url and after the link is copied it is often referred to with some of the slug words. The url with "Solution-to-your-problem" may have Solution to your problem inside the a tag also when people link to your page. This will influence your ranking.
A solution with id + slug might be the best solution and it fixes the problem of keeping track of slug changes.
test.com/85583/solution-to-your-problem
But there are some rules to follow, you should do a 301 redirect if the slug is incorrect to prevent a lot of duplicate content pages. Spam/duplicate content detecting kicks in if you got a lot of similiar pages:
test.com/85583/solution-to-your-problem
test.com/85583/solution-to-yar-problem
test.com/85583/evil-competitor-spamming-you-haha
Including the id also requires your ids to be as short as possible, an url with a full guid might be confusing to the eye and prevent a good clickthrough:
test.com/0CD03822-4A35-11DE-BF38-3F9356D89593/solution-to-yar-problem
Remember that Google News even demanded that you had an id in your url to be included.
Well, my name is Sudhir Jonathan, so if I want people to find me on your site, example.com/user/sudhir-jonathan is much much better than example.com/user/1234. Simply because the object of your page - "Sudhir Jonathan" - is now present in the url itself. This is a big win.
Similarly, example.com/articles/how-to-bake-a-cake is ranked much higher than example.com/articles/2379797 for the search term "bake a cake".
See this Do SEO-friendly URLs really affect a page’s ranking? question. Based on the answers, no-one can find any proof that IDs in the URLs has any effect on SEO.
It simple, search engines care words rather than number. That is to say, it will be better to see keywords in url than just ID sine ID/number is useless for search engines to determine whether your site is relevant or not!
It's always a bad idea to provide unusual information. Try the user name instead!
For SEO there is no real advantage/disadvantage between static ID urls and username urls.
1) you miss out on keywords in the url
2) it's harder for a human to read and understand what the link will be about
3) sql injection is a lot easier with IDs
I have a application where we are using react on some pages. Its a pretty large site and turning it into a SPA would be pointless as most of the content is static.
However on the pages where we need things to be interactive i am using react and react-redux.
So i have a search page that builds a list of filters (aggregates from elastic search) that lets people filter down their search results (same thing 90% of the web is doing with search). This page is using react.
Lets say i click a filter for manufacturer, and then i apply a filter for a price range of some kind. I want to be able to hit the back button or click the back button and have it remove the last filter or more specifically move the state back to its previous version. I know this is possible but i keep smacking into react-router and SPA type answers/tutorials/documentation online.
Thanks in advance!
Looks like you need a history: redux-undo may help you with this.
About back button — do you mean that you want to intercept history.back and undo filter in this case? If so — you should add a hash to a window.location on every change of filter. So in this case, there are few strategies:
You can store all filtering settings in the hash. And update redux state on changes. It might be useful for sharing a link, but it may be dangerous (you have to validate this data) and a link could be very long (it's like ?filter[type]=cars&filter[colour]=red&... in the old-fashioned PHP websites).
You can use redux-undo and for each new history state just push something like history counter (incremental from 0 for every change in the history) into window.location.hash. So then you just can dispatch jumpToPast(indexFromHash). But if you want to give a user possibility to share the page with defined filters — you need to figure out how.
I'm sure there are some more solutions but I think they will like these or be even more difficult (using historyAPI and other things). So you can leave your choice on this.
If this doesn't fit you — just write why and tell more information. I'll update my answer.
I am using AJAX to load content dynamically, in my page. (basically I have a search bar, and the search results are obtained using AJAX).
I want to make use of History API, since, After several searches(and also applying sorting and filter), if the user press browser back button, it takes them directly out of my site, instead of taking them to the previous search result.
There are several online resources about using history API, but I could find any information regarding the URL, that needs to be set using
window.history.pushState(dataObj, title, URL);
If we just set any URL maybe like www.mypage.com/value1, then, this would become a fake URL, which if bookmarked and used later, will not work.
So I was thinking of using the following appoach.
1)Set the URL to www.mypage.com?variable1=value1&variable2=value2 .....
Where value1 and value2 ... would be some information, which I use for AJAX.(In my case these values would be the search text and the filter and sort information)
2)On press of back button, retrieve the URL, spit it using "?" and "&" separators, and take action accordingly
3)If this URL is bookmarked also, I can handle it appropriately, since all the information is available as variables.
So, My question is, Is this a right approach, or is there any better(standard) way of handling such scenario ?
This is somewhat opinionated, but I think your approach sounds fine. So long as the user is able to press the back button and directly visit the URL to get the same results, then I think it is a perfectly fine way of doing it, and I cannot necessarily think of a better way.
In fact, from what I could grasp after looking into the Google search javascript code, it seems like they use a very similar method. They use history.pushState(...) to add search query URLs to browser history, and when they initialize the window, they check the history object as well as the URL to decide what search results to load using JS. That is not to say that Google is the go-to guru for proper web development, but if they are using a method like that, I think it is pretty safe to say that you would be fine to use it too.
I would definitely be interested if anyone has a better way, because that seems to be the best.
Users will be able to write some documents. Those documents will consists of chapters (one-to-many relation).
Normally I would do this by creating separate views for creating chapter and document.
How to implement web page that allow to edit "composite" view? Where I can edit document details, but also create chapters, without visiting different pages? Also how can I ensure that I pass order of chapter user have arranged (by moving chapters freely up and down)?
(Sorry if that question already have be asked&answered but I do not even know how to search for it :| since I do not know proper keywords beyond "AJAX", so help in naming my requirement would also be welcomed!)
Backend servers applications based on REST principles work nicely with Ajax client-side implementations.
For example, your URLs could be:
/book/1
/book/1/chapters
/book/1/chapter/1
You could set it up so that a POST to /book/1/chapters would add a chapter. A GET on that same URL would return all chapters. A GET on /book/1/chapter/1/ would only return chapter 1. A PUT on /book/1/chapter/1/ would update an existing chapter. This is a "RESTful" architecture:
http://en.wikipedia.org/wiki/Representational_state_transfer
This is an interesting introduction: http://tomayko.com/writings/rest-to-my-wife
This is a big subject, but if you create the right backend server architecture you will find your job a lot easier. Hope this helps answer your question.
Ok Partial solution.
Just google Nested Forms Ruby on Rails. Plenty of examples, all in ajax, all easy.
Currently our website uses links to allow the user to change their locale. The problem with this is that you get a lot of random outlinks from each page on the site to... the same page, in other languages. When a search engine traverses this, it gets an excessively complex view of the site.
We were going to change it to a form post to avoid this. However, it seems to me that we should just be able to change it to an onclick="window.location.href='change_my_language.php'" rather than an href="change_my_language.php". Am I right? Or do the major search engines scan for and follow this sort of thing nowadays?
To solve the larger problem of duplicate content, you can use the canonical link tag to specify on the pages in other languages the URL of the preferred document.
<!-- on http://www.example.com/article.php?id=123&language=something-else -->
<link rel="canonical" href="http://www.example.com/article.php?id=123" />
To save search engines the trouble of landing on the other pages, it wouldn't hurt to add rel="nofollow" to the links, to ensure that robots don't waste their time checking them out. However, the canonical link tag is still vital, in case someone links to your other-language content, to ensure that your preferred page gets the ranking credit.
I'm fairly certain search engines don't parse JavaScript, so any code that changes the value of any property of the location object wouldn't follow the URL.
EDIT
An interesting article on the topic: http://www.seroundtable.com/archives/019026.html
and bobince's answer on this potential duplicate question suggests the same: window.location and SEO
POST method must be used when the request changes server's state, i.e. request has side-effects:
http://www.cs.tut.fi/~jkorpela/forms/methods.html
No, search engines won't be able to follow javascript links, but POST is more elegant solution.
When a search engine traverses this, it gets an excessively complex view of the site.
This should not be a problem. As long as you are correctly marking up each page with lang="...", the search engine should know what to do with it. What is the actual problem you are facing that leads you to believe search engines are confused by a ‘complex’ link map?
You can give them a sitemap if you really want to be explicit.
However, it seems to me that we should just be able to change it to an onclick="window.location.href='change_my_language.php'" rather than an href="change_my_language.php"
That would degrade the site's usability and accessibility a little as well as (deliberately) sabotaging the search engine.
In any case, whatever you do you should definitely leave each language version on its own URL (eg. /en/category/title) rather than totally relying on a language-setting cookie, or you really do run the risk of confusing search engines. Normally you do want search engines to index every language version you have, to catch searches from users of other languages.
Google is getting increasingly better at parsing JavaScript. I don't think that the search engines will follow this link now...but to be more certain they don't follow you can change your anchor tags to spans instead and use the onclick="document.location='url'" method.
Though what you may want to do is add rel="nofollow" to these links instead. You can also add a canonical link to the main page.