: Fetch as Google ignores my hashtag url I have an AngularJS web application: www.webisports.com I am using ng-router, so all my pages have # in the url. I want google to index my /#/forum page.
I have an AngularJS web application:
webisports.com
I am using ng-router, so all my pages have # in the url.
I want google to index my /#/forum page.
This stackoverflow answer explains how to make AngularJS indexed by Google:
To generate real URLs in Angular, rather than # prefixed ones, set HTML5 mode on your $locationProvider object: $locationProvider.html5Mode(true);
Since you are using real URLs, you will need to ensure the same template (plus some precomposed content) gets shipped by your server for all valid URLs. How you do this will vary depending on your server architecture.
I followed this tutorial to make it work.
As mentioned in the article above, my server should respond to /forum requests, so I redirect the request from /forum to /#/forum and use HTML5 to change the url back to /forum. This works as expected.
My problem is with Fetch as Google. When I try to fetch the page /forum as Google, it tells me that this page is redirected to /#/forum (obviously). and when I try to fetch /#/forum, Google ignores the # and everything after it and fetches /.
How do I fetch my /forum page?
And how do I make sure Google indexes it?
More posts by @Welton855
1 Comments
Sorted by latest first Latest Oldest Best
The # in a URL represents a specific part of the resource to link to. In an HTML document, for instance, it describes the ID of the element (and browsers will scroll to it).
The # and the data after it as never sent to the server. They are handled purely client side.
In the bad old days, single page applications used the data after the # to fake having distinct pages.
The browser asks for /, and it gets the homepage.
The browser asks for /#!foo and it gets the homepage, and then some JavaScript runs which transforms it into a different page.
This is, obviously, bad food for search engines (although, these days, search engines tend to be better at coping with that type of hack).
Then the History API came along and pushState allowed the local part of a URL to be changed without actually loading a new page. This allows JavaScript on the page to transform the content to /foo without loading /foo from the server from scratch.
The idea is, that when you do that, you also set up the server so it can deliver /foo from scratch. This gives you a page that:
loads directly without flashing up the homepage
works when the JS fails
provides good food for search engines
You are just redirecting people back to the homepage and trusting the JS to populate all the content. You should make the server deliver a real page instead.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.