For a pretty complex website we are looking on how we can best create internal links between pages without creating complex logic to calculate the url for the target pages when rendering the page.
For example if we wanted to link to www.domain.com/nl/holiday/hotels/holiday-inn/ we are thinking to put an intermediate linkthrough page between the two. Something like www.domain.com/go/hotel/234 which would just calculate the correct url path and forward to the target url. This prevents us from needing to do all the translations and slug calculations on the page that is being rendered which saves us quite some resources and trouble.
Does this technique have some drawbacks that we need to be aware of? From both technical and SEO view?
It really shouldn't be that resource intensive to calculate some slugs. If it is, you may want to think about how your queries and code work and see if you can refactor them in some way. But even if you had a few extra queries a page, it wouldn't slow down your pageload time by any real noticeable amount.
I don't think it's a good idea to have an intermediate page either. If you were setting a redirect header, it certainly wouldn't help your SEO, and neither would making your users wait an extra couple of seconds every time they want to open a page.
Find a way to cheaply generate your slugs, don't use an intermediate page.
Related
I've got this grid (a list of products in an internet shop) for which I've no idea how big it can get. But I suppose a couple hundred items is quite realistic, especially for search results. Maybe even thousands, if we get a big client. :)
Naturally, I should use paging for such a grid. But how to do it so that search engine bots can crawl all the items too? I very much like this idea, but that only has first/last/prev/next links. If a search engine bot has to follow links 200 levels deep to get to the last page, I think it might give up pretty soon, and not enumerate all items.
What is the common(best?) practice for this?
Is it really the grid you want to have index by the search engine or are you afer a product detail page? If the last one is what you want, you can have a dynamic sitemap (XML) and the search engines will take it from there.
I run a number of price comparison sites and as such i've had the same issue as you before. I dont really have a concrete answer, i doubt anyone will have one tbh.
The trick is to try and make each page as unique as possible. The more unique pages, the better. Think of it as each page in google is a lottery ticket, the more tickets the more chances you have of winning.
So, back to your question. We tend to display 20 products per page and then have pagination at the bottom. AFAIK google and other bots will crawl all links on your site. They wouldnt give up. What we have noticed though is if your subsequent pages have the same SEO titles, H tags and is basically the same page but with different result sets then Google will NOT add the pages to the index.
Likewise i've looked at the site you suggested and would suggest changing the layout to be text and not images, an example of what i mean is on this site: http://www.shopexplorer.com/lcd-tv/index.html
Another point to remember is the more images etc... on the page the longer the page will take to load the worse your UI will be. I've also heard it affects quality on SEO ranking algorithms.
Not sure if i've given you enough to go on, but to recap:
i would limit the results to 20-30
I would use pagination but i would use text and not images
i would make sure the paginated pages have distinct enough 'SEO markers' [ title, h1 etc.. ] to be a unique page.
i.e.
LCD TV results page 2 > is bad
LCD TV results from Sony to Samsung > Better
Hopefully i've helped a little
EDIT:
Vlix, i've also seen your question ref: sitemaps. If you're concerned with that, i wouldnt be, then split the feed into multiple seperate feeds. Maybe on a category level, brand level etc... I'm not sure but i think google would want as many pages as possible. It will ignore the ones it doesnt like and just add the unique ones.
That at least, is how i understand it.
SEO is a dark art - nobody will be able to tell you exactly what to do and how to do it. However, I do have some general pointers.
Pleun is right - your objective should be to get the robots to your product detail page - that's likely to be the most keyword-rich, so optimize this page as much as you can! Semantic HTML, don't use images to show text, the usual.
Construct meaningful navigation schemes to lead the robots (and your visitors!) to your product detail pages. So, if you have 150K products, let's hope they are grouped into some kind of hierarchy, and that each (sub)category in that hierarchy has a managable (<50 or so) number of products. If your users have to go through lots and lots of pages in a single category to find the product they're interested in, they're likely to get bored and leave. Make this categorization into a navigation scheme, and make it SEO friendly - e.g. by using friendly URLs.
Create a sitemap - robots will crawl the entire sitemap, though they may not decide to pay much attention to pages that are hard to reach through "normal" navigation, even if they are in the sitemap.xml.
Most robots don't parse more than the first 50-100K of HTML. If your navigation scheme (with a data grid) is too big, the robot won't necessarily pick up or follow links at the end.
Hope this helps!
I run an online shop and I wonder what would be more SEO-friendly URL for a product page:
a) domain.com/category-name/product-name OR
b) domain.com/product-name
I already have URL-s for product category pages with format domain.com/category-name.
On one hand I heard (but cannot find proof for) that Google like tree hierarchies in URL (vote for "a"). On the other hand though longer URL could lead to smaller kewyord density, also "product_name" comes as the last URL part so probably the least important (vote for "b"). Maybe both options are equally SEO-effective?
PS. I know about canonical URL's but this is not the case, I don't want/need both URL's formats, just want to choose the best.
In my opinion, category-name/product-name might drive more traffic compared to just product-name. Because former one has the advantage of two keywords, while the later just has one.
But, it may affect the results when user just searches for product-name. Because search engines will prefer the keyword which comes very first in the url. In this case, product-name will defeat category-name/product-name.
So, it depends on the product and category you are going to use. How the users will address the product. simply the product or always with the category name. Just do a little keyword research and decide which one to go with.
In a client case of mine, including both category and product name in the URL rendered much better SEO results. I have no empiric references, though. The keyword density landed on about 9-11 %.
smaller url are better. hard to manage as links grows.
so if you can do domain.com/product-name
nothing beats it. and it looks great on search result.
A sites URL structure should be as simple as possible:
Google Webmaster Central Advice on URL structure
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=76329
http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html
Google does highlight the search terms if they appear in the URL.
In Googles words:
"While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking."
As https://stackoverflow.com/users/290503/iamgopal stated. Smaller is better. More important if you use the category and at a later time you decide to put your product in another category you have changed the url. Which is not good even if you redirect.
We actually removed all categories from our url's (8 million products or so) to make re-categorization easier. We haven't noticed a significant drop in ranking after the redirect effect wore off.
What are the standards for managing URL redirects if you base your URL's off properties of the data that might change a few times, like the "title"?
I have a website with lots of images and I want to make the urls look like this:
http://www.mySite.com/images/132123/my-cool-image-title
Now say a bunch of people bookmark the image, and a week later I change it to:
http://www.mySite.com/images/132123/renamed-image-title
So now there has to be a redirect for the people that bookmarked the old one... Now lets say that happens on average 3 times per image. That means I'd have lots and lots of redirects to map. I'd have a database of redirects it seems.
What is best practice in this case, assuming I want to use pretty urls and not base it on some universally unique id, and that I'd like to reap as many benefits of SEO as possible?
Well I don't know what the downvote was about, this seems like a perfectly valid question to me.
My recommendation would be that if you know in advance you will be changing the data, it probably shouldn't be in the URL in the first place. If this is a requirement (perhaps its important for SEO or you are creating a blog or something, you have some choices:
Forget the old URL and use only the new. Probably not a good way to make friends ;)
Keep the old URL and accept the fact that the title and URL do not match now. This might be accomplished by each post having a slug field where the URL text is stored, separate to the post's actual title.
Keep the old URL and allow for new ones. A method for doing this might be to have a separate table which maps slugs to posts, each post having one or more slugs. That way, any number of changes are catered for.
If possible changes and backwards compatibility are a requirement, I'd go with something like option 3. Its certainly better to have it built in to your app than have to manage growing .htaccess files full or URL rewrite rules or something.
vote me down if you think my answer is stupid. I do not care it so much.
Not sure if your are using the same approach as StacOverflow, if you do then the slug, in your case my-cool-image-title and renamed-image-titledo not make a big difference as long as you keep the ID 132123 the same. So you need to to worry about your redirect stuff. That being said, in the perspective of social Bookmark users, I think changing slug may cause confusing, but it is not a redirect issue.
Am I wrong?
If I name my HTML file "Banks.html" located at www.example.com/Banks.html, but all the content is about Cats and all my other SEO tags are about Cats on the page, will it affect my page's SEO?
Can you name your files whatever you want, as long as you have the page title, description, and the rest of the SEO done properly?
Page names are often not very representative of the page content (I've seen pages named 7d57As09). Therefore search engines are not going to be particularly upset if the page names appear misleading. However, it's likely that the page name is one of many factors a search engine considers.
If there's no disadvantage in naming a page about cats, "cats.html", then do so! If it doesn't help your SEO, it will make it easier for your visitors!
If you want to be on better place when someone searchs for 'banks', then yes, it can help you. But unless you are creating pages about cats in banks I'm sure that this wont help you very much :)
It shouldn't affect your search engine ranking, but it may influence people who, having completed a search on Google (or some of the other great search engines, like um...uh...), are now scanning the results to decide where to click first. Someone faced with a url like www.dummy.com/banks.html would be more likely to click than someone faced with www.dummy.com/default.php?p_id=1&sessid=876492u942fgspw24z because most people haven't a clue what the last part means. It's also more memorable and gives people greater faith in getting back to the same site if you write your URLs nicely. No one that isn't Dustin Hoffman can remember the second URL without a little intense memory training, while everyone can remember banks.html. Just make sure your URL generation is consistent and your rewriting is solid, so you don't end up with loads of page not found errors which can detriment search engine ranking.
Ideally, your page name should be relevant to the content of the page - so your ranking may improve if you call the page "cats.html", as that is effectively another occurrence of the keyword in the page.
Generally, this is fairly minor compared to the benefits of decent keywords, titles, etc on the page. For more information take a look at articles around Url Strategy, for example:
"I’ve heard that search engines give some weighting to pages which contain keywords users are searching for which are contained within the page URL?"
Naming your pages something meaningful is a good idea and does improve SEO. It's another hint to the search engines what the page is about, in addition to the title and content. You would be surprised if you opened a file on your computer called "Letter to Grandma.doc" and it was actually your tax return!
In general, the best URLs are those that simply give a page name and hierarchical structure, without extensions or ID numbers. Keep it lowercase and separate words with dashes, like this:
example.com/my-cats
or
example.com/cats/mittens
In your case you will probably wanna keep the .html extension to avoid complexities with URL rewriting.
Under circumstances this can be considered a black-hat SEO technique. Watch out not to be caught or reported by curious users.
Google's PageRank algo has hundreds, thousands or even millions of variables and factors. From this point of view, you can be sure that the name of the files that you use on your website will affect your pagerank and/or your keyword targeting. Think about it.
There are few on-page elements that have significance. The URL, while it can be /234989782 is going to be more beneficial if it's named relevantly.
From any point of view, Google and all search engines like to see a coherence between everything: if you have a page named XYZ, then google will like it better if the text, meta, images, url, documents, etc, on the page to have XYZ in them. The bigger this synchronisation between the different elements on a page, the more the search engine sees how focused the content of that page is, resulting in more hits for you when someone looks up that focused search term.
If you have an image for example, you're better off having the same:
caption
description
name
alt text
(wordpress users will recognize that these are the four parameters that can be set for images on wordpress).
The same goes for all files you have on your website. Any parameter that can be seen by a search engine is better of optimized in regards to the content that goes with it, in sync with all the other parameters of this same thing.
The question of how useful this all is arises afterwards. Will I really rank lower if my alt text is different than the name of my image? Probably not by a lot. But either way, taking advantage of small subtleties like these can take you a long way in SEO. There are so many things we can't control in SEO (or that we shouldn't be able to control, like backlinks), that we have to use what we can control in the best way possible, to compensate.
It's also hard to tell if it is all useful after the Google Panda and Penguin. It definitely has less of an impact ever since those reforms (back then, this kind of thing was crucial), the question is simply how much of an impact it still has. But all in all, as I said, whenever possible, name your files according to your content.
Today algorithm is totally different when the SEO was introduce. The seo today is about content and its quality. It must produce a good reader and follower so any filename and description are no longer important.
Page name doesn't affects much in terms of SEO. but naming a page is also one of the Google 200 SEO signals.
Naming a url different sure will reduce your bounce rate a little. Because any user comes to your site through organic search results doesn't understand what the page has.
Even search engines loves when a page name is relevant to the topic in the page.
On the advice of a more experienced developer, I have always coded my web pages that require user input (form processing, database administration, etc.) as self-referential pages. For PHP pages, I set the action of the form to the 'PHP_SELF' element of the $_SERVER predefined variable, and depending on the arguments that I pass the page logic determines which code block(s) to execute.
I like that all of the code is contained in one file, and not spread around to various result pages. The one issue I've found is that my stats parsing programs can't differentiate between the first view of the page, and subsequent views (e.g. when the form has been submitted). A long time ago, when I used CGI or CF to create the pages, I directed the user to a different result page, which showed very neatly how many times the form was actually used.
What is the best practice for these types of pages in web development? Are there other, more compelling reasons for using (or not using) self-referential pages?
I would argue that self-referential pages, as you put it, do not follow an appropriate separation of concerns. You're doing 2 different things with the same page, where a cleaner separation of logic would have you do them in 2 different pages.
This practice is emphasized by MVC (model-view-controller, http://en.wikipedia.org/wiki/Model-view-controller) frameworks, such as Ruby on Rails, Django, and ASP.NET MVC (I don't know any PHP ones off the top of my head, though I am sure there are some).
This is also an essential feature of RESTful (REpresentational State Transfer) practices, where each URL represents a resource and a single action to be performed with that resource. A self referential page, on the other hand, would have "2" actions per URL/page, such as "new" (to get the form to fill out) and "create" (to actually create the object).
Practicing MVC and RESTful (http://en.wikipedia.org/wiki/RESTful) practices for websites often results in cleaner code and a better separation of concerns. The reason this is important is that it makes for easier testing (and by testing I mean unit and functional testing, not "trying the page on my browser" testing).
The cluttering of your statistics is an example of how not separating your concerns can lead to un-intended complexity. Some people might approach this problem by trying to detect the referrer of the request, and see if it was the same page or not. These are all really just code-bandages that address the symptom, instead of fixing the problem. If you keep different "actions" in different pages in your website, you can focus those pages on their 1 job, and make sure they do it well, instead of cluttering the code with all sorts of conditionals and additional complexities that are completely avoided if 1 page only has 1 job.
The strongest argument behind the single file approach for form handling is that it's simply easier to maintain.
Allow me play devil's advocate: if your original two file approach works and is measurable, why change it -- particularly if changing it forces you to come up with workarounds to measure the form submission?
On the other hand, if you're dealing with something more complex than what I'm imagining as a simple contact form submission (for example) then it might behoove you to learn how to log your actions instead of depending on a web stats package.
In the case where I'm asking someone to fill out a form (generated by the script in a file), I like posting back to the same script so that I can put the error checks at the top, and then re-generate the form if any errors are found. This allows me to write the form generation once and re-use it until the input is acceptable (i.e. "Please correct the fields shown in red", etc.).
Once the input passes all the sanity checks, you can emit the results page from the same script, or call off to another script, depending on which is cleaner for your situation. But I personally see no problem with the self-referential scripts you describe.
That said, I always call on generic code and libraries to do the form generation and error checking, so even this "shared" form generation code ends up being fairly compact and simple.
One potential option would be to set up mod_rewrite aliases that point at the same URL. For example:
RewriteEngine on
RewriteRule ^form$ form.php [QSA]
RewriteRule ^form/submit$ form.php [QSA]
This would allow you to track requests while maintaining the code in the same file.
You could use separate pages, and just have the results page include the form page.