My site uses pagination to get to different event pages. The problem is, these conferences on these pages are not getting picked by search engines. Below is my code...
1
2
What can I do for SEO so Google will crawl and find all of the conferences on the other pages?
Make real pages with real URLs.
Link to the real pages instead of to javascript:;.
Cancel the default behaviour of the link (by returning false if you are going to keep using onclick attributes) so that the JS still has the effect you want.
Use pushState and friends to update the URL and make the back button work.
Related
I designed a website in which the whole site is contained within one page (index.php).
Within the page, <section> tags define different parts of the site (home, contact, blog etc.)
Navigation is achieved by buttons that are always visible, and when clicked use javascript to change the visibility of the sections, so that only one is shown at any time.
More specifically, this is done by using the hash in the url, and handling the hashchange event. This results in urls such as www.site.com/#home (the default if no other hash is present) and www.site.com/#contact.
I want to know if this is a good design. It works, but I get the feeling there must be a better way to achieve the same thing? To clarify, I was aiming for site that loaded all the main content once, so that there were no more page loads after the initial load, and moving between sections would be smoother.
On top of this, another problem is introduced concerning SEO. The site shows up in google, but if for example, a search query contains a term in a specific section, it still loads the default #home page when clicked, not the specific section the term was found in. How can I rectify this?
Finally, one of the sections is a blog section, which is the only section that does not load all at once, since by default it loads the latest post from a database. When a user selects a different post from a list (which in itself is loaded using AJAX), AJAX is used to fetch and display the new post, and pushState changes the history. Again, to give each post a unique url that can be referenced externally, the menu changes the url which is handled by javascript, resulting in urls such as www.site.com/?blogPost=2#blog and www.site.com/?blogPost=1#blog.
These posts aren't seen by google at all. Using the Googlebot tool shows that the crawler sees the blog section as always empty, so none of the blog posts are indexed.
What can I change?
(I don't know if this should be on the webmasters stackexchange, so sorry if its in the wrong place)
Build a normal site. Give each page a normal URL. Let Google index those URLs. If you don't have pages for Google to index, that it can't index your content.
Progressively enhance the site with JS/Ajax.
When a link is followed (or other action that, without JS, would load a new page is performed) use JavaScript to transform the current page into the target page.
Use pushState to change the URL to the URL that would have been loaded if you were not using JavaScript. (Do this instead of using the fragment identifer (#) hack).
Make sure you listen for history events so you can transform the page back when the back button is clicked.
This results in situations such as:
User arrives at /foo from Google
/foo contains all the content for the /foo page
User clicks link to /bar
JavaScript changes the content of the page to match what the user would have got from going to /bar directly and sets URL to /bar with pushState
Note that there is also the (not recommended) hashbang technique which hacks a one-page site into a form that Google can index, but which is not robust, doesn't work for any other non-JS client and is almost as much work as doing things properly.
To go back to the appropriate tumblr page, we're using:
Back
However, we're getting a lot of traffic directly from the twitter app, and this stops the function working. Is there a way so that if the history.go doesn't work (or takes you outside the site), it will just take you to index.html?
This is one of the pages the history button is on: http://lexican.info/post/49265445109/sesquipedalophobia
Thanks for any help at all.
Sadly I don't think this is possible as there is no relationship between a post and what page of the index the post is displayed on.
Try to check how many page in the history list with history.length:
http://www.w3schools.com/jsref/prop_his_length.asp
I have a section of a site with multiple categories of Widget. There is a menu with each category name. For anybody with Javascript enabled, clicking a category reveals the content of the category within the page. They can click between categories at will, seeing the DOM updated as needed. The url is also updated using the standard hash/hashbang (if we are being Google-friendly). So for somebody who lands on example.com/widgets, they can navigate around to example.com/widgets#one, example.com/widgets#two, example.com/widgets#three etc.
However, to support user agents without Javascript enabled, following one of these category links must load a new page with the category displayed, so for someone without javascript enabled, they would navigate to example.com/widgets/one, example.com/widgets/two, example.com/widgets/three etc.
My question is: What should happen when somebody with Javascript enabled lands on one of these URLS? What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
Please note that I need a single page site experience for anybody with Javascript enabled, but I want a multi-page site for a user agent without JavaScript. Any answer that doesn't address this fact doesn't answer the question. I am not interested in the merits or problems of hashbangs or single-page-sites vs multi-page-sites.
This is how I would structure it:
Use HistoryJS to manage the URL. JS pushstate browsers got full correct URLs and JS non-pushstate browsers got hashed urls. Non-JS users went to the full URL as normal with a page reload.
When a user clicks a link:
If they have JS:
All clicks to other pages are handled by a function that prevents the default action, grabs the HREF and passes the URL to an ajax request and updates the URL at the same time. The http response for that ajax request is then parsed and then loaded into the content area.
Non JS:
Page refreshed as normal and loads the whole document.
When a page loads:
With JS: Attach an event handler to all your links to prevent the default so their href is dealt with via Ajax.
Without JS: Nothing. Allow anchors to work as normal.
I think you should definitely have all of your content accessible via a full, correct URL and being loading it in via ajax then updating the URL to reflect the address where you got your content from. That way, when JS isn't running, you don't have to change anything.
Is that what you mean?
Apparently your question already contains the answer. You say:
I need a single page site experience for anybody with Javascript enabled
and then ask:
What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
I'd say yes, they should be redirected. I don't see any other option, given your requirements (and the fact that information about JavaScript capabilities and the hash fragment of the URL are not available on the server side).
If you can accept relaxing the requirements a bit, I see another option. Remember when the web was crowded with framesets, and we landed on a specific frame via AltaVista (Google wasn't around yet!) search? It was common to see a header saying that page was supposed to be displayed as a frame, and a link to take the user to the frameset version.
You could do something similar: when scripting is available, detect that you're at example.com/widgets/one and add a link to the single-page version. I know that's not ideal, but it's better than nothing, and maybe better than a nasty client-side redirect.
Why should you need to redirect them to a different page. The user arrived at the page looking for an answer. He gets the answer even if he has javascript enabled. It doesn't matter. The user's query has been fulfilled.
But what would happen if the user lands on example.com/widgets#one ? You would need to set up an automatic redirect to example.com/widgets/one in that case. That could be done by checking the if javascript is enabled in the onload event and redirect to the appropriate page.
One way for designing such pages is to design without javascript first.
You can use anchors in the page so:
example.com/widgets#one
Will be a link to the element with id 'one'
Once your page works without javascript, then you add the javascript layer. You can prevent links to be followed by using the event.preventDefault.
(https://developer.mozilla.org/fr/docs/DOM/event.preventDefault), then add the desired javascript functionality.
I was wondering if using Lightbox all over the site would be a smart idea.
We are developing an eCommerce site and the idea is to keep the user on the main page all the time and show all the content (Product Page, About us etc) in a Lightbox way.
I understand that in order to use Lightbox you'll need Prototype/JavaScript which are widely supported at most browsers, I'm also aware that Ligthbox on mobile is not really fun but we are going to create a mobile version anyhow, A few Qs:
Do you think Lightbox might be heavy somehow? will it reduce site performance?
Do you think there are going to be big compability issues?
Any other thoughts why that not such a good idea? Again, the main idea is to keep the user at the main page while he can browse 'less important'.
Thanks in advance.
I think it's not a good idea to use lightbox massively to show relevant content for many reason
Accessibility: you cannot rely only on javascript to access the information so you need to put much more effort to develop with progressive enhancement. How if I navigate products through the browser history?
SEO: have you thought how to make your products retrievable by search engines? To make dynamic content indexable you will need again more extra effort. Consider also the possibility of being penalized for hidden contents on the page.
Usability: How would you deal with multiple devices and screen resolution? What if you show the image product in a lightbox and then your customer ask to also show the zoom images in a lightbox too? Will you open nested lightbox?
Social Network : "like" and "+1" are common functions on almost every modern e-commerce: but these actions can be performed only on a single URL, so if your products are not associated to a specific url (1 to 1 relation) you won't be able to share a specific item.
So, It's better to avoid all these complications
Use instead lightbox for giving alerts, show modal window and tell the user about the result of some server operation (e.g. Login/logout messages, alert the end of stock for an item during checkout...) and, in general, everywhere it's better not to completely change or break the navigation flow (e.g. registration, checkout,...), but definitely avoid to organize the entire site in lightboxes.
If you are developing an e-commerce site, then its not a good idea to use lightbox style ajax for loading all pages, because then search engines will not be able to index your products and display to people on search results.
In the past, I've used Fancybox over Lightbox mainly because I found it to be more flexible for my needs.
I too have created a online store using Fancybox with embedded popups to give the user more information on a popup.
What I would say is that to ensure page performance is not hindered, do not render a Fancybox popup through a hidden div on the page. If the hidden div contains a lot of images and content, this will cause some overhead.
The way I've used Fancybox is by loading an external page as its content source:
$("#product-info").fancybox({
titleShow : false,
width: 500,
height: 600,
autoDimensions: false,
overlayOpacity: 0.6,
href: 'product-info.aspx?ID=9' // External page source
});
I think just use a Fancybox/lightbox with caution. Only add basic product content. Keep the detailed for the product page itself. This will help Google searches (as other people have commented).
I agree with all of F.Calderan's points except maybe the last. I think there is a common use case in the "Quick View" seen on many clothing sites that could work for you. It provides a similar experience to the one you describe while not replacing all the benefits of having multiple pages.
See Old Navy for an example.
How to make Contents table for a GWT page, for the purpose of bookmarking and direct jump to a subsection of a dynamic page.
Address for my webApplication is like,
www.example.com/WebApp#param1=value1¶m2=value2
This link displays a page with many subsections, i want to provide feature for users to be able to bookmark and load subsections directly.
You can use the History class to get access to the URL after the # and react accordingly. It works really well, and is the officially recommended way of solving this problem.
A short tutorial: http://www.bluecoders.com/tutorials/gwthistory.html
Basically, History is a static class on which you can call addValueChangeHandler to register an object that should deal with any history changes. This supports direct linking (e.g. bookmarks) and also proper navigation when the user uses the back and forward buttons in the browser.