Im planning to add language feature to my site. I can see two ways:
storing language in the url, so always www.mysite.com/en/introduce, www.mysite.com/en/home, or if 1st parameter is missing, just use the default. Its good for bookmark, but very hard to implement to all available links
storing in session. Way much easier, but users may gets confused not seeing the language in the URL.
I would say: session. What would you say? Any experiences?
If you want all your pages to be indexed by search engines, you'll have put the language parameter in the URL.
If you're producing more something like Facebook where a user needs to be logged in to receive content in his personalized language, use sessions.
I would use the first method togetter with a url rewrite engine.
F.e. when using RewriteEngine for Apache you could add this line to your .htaccess:
RewriteRule ^([a-zA-Z][a-zA-Z])/([a-zA-Z]*)$ content.php?culture=$1&content=$2
and even this can work:
RewriteRule ^([a-zA-Z][a-zA-Z])/([a-zA-Z]*)$ $2.php?culture=$1
You want to put your language as part of the url, otherwise google won't be able to index it for different countries. Also, they might think you have two types of content on the same page.
I would store it in session if there's only some parts of content changing as it's easier to implement if you're just changing i.e. contact details for the company based on what country the user is coming from. But as a general rule, give it a separate url either using .htaccess or your routing system.
Regular users don't look at URL and change the parameters from there. Normal users are point and click. Keep the language selection somewhere visible on the page and also in the user settings. This is not something that a user will want to change several times during a visit. We are talking about a setting that you can ask and set on the first visit. Currently I hate the way the google does it using my IP, assuming (wrong) that if I am entering from Norway I definitely speak Norwegian and I can handle finding in Norwegian menus the English version. I do like the way Etsy.com is doing it, they ask you on the first visit what is your preferred language, currency and so on. If you accept them good, but you can change them right there without having to navigate to a menu. In my opinion go for cookies or session instead of polluting the URL.
Related
I have a specific requirement and am looking for suggestions on the best possible way to achieve that. I would start by apologizing if I sound too naïve. What I am trying to achieve in here is:
A) I have a parent site, say, www.abc.com.
B) I am planning to enable multisite option for it. This parent site has a area map with a number of location images overlayed. All of these images, when clicked, should lead to a subsite.
C) This subsite (has already been coded) is totally dynamic and every single information being displayed on it is being extracted from the database. It uses a session variable, which for now has been hard-coded at the very beginning of the header. This variable also decides on which database to refer to. So it will display information for different locations, based on the location selected on the parent site. Even the URL should appear per that. Say if Location ‘A’ was clicked on parent-site then the session variable needs to set to ‘LocA’ on the sub-site and the URL should be something like www.abc.com/LocA and if the Location ‘B’ was clicked then the session variable should be set to ‘LocB’ and the URL should appear as www.abc.com/LocB etc.. Trying to figure out how to achieve this. [It will have one front-end for all the locations but different databases for each location.]
I am an entrepreneur with some programming experience from my past (but none related to website designing). Because of the help from all you geniuses and the code samples lying around, I was able to code the parent site and the sub-site (using html, php, js, css ). Now the trouble is how to put it all together and make it work in correlation. Though it will still be a week or two before I get to try it but I am trying to gather insights so that I am ready by the time I reach there. Any help will be deeply appreciated.
I think the fundamental thing to understand before you get deeper is what a URL is. A URL is not part of the content that you display to the user; nor is it the name of a file on your server. A URL is the identifier the user sends your server, which your server can use to decide what content to serve. The existence of "sub-sites", and "databases", and even "files" is completely invisible to the end user, and you can arrange them however you like; you just need to tell the server how to respond to different URLs.
While it is possible to have the same URL serve different content to different users, based on cookies or other means of identifying a user, having entire sites "hidden" behind such conditions is generally a bad idea: it means users can't bookmark that content, or share it with others; and it probably means it won't show up in search results, which need a URL to link to.
When you don't want to map URLs directly to files and folders, the common approach involves two things:
Rewrite rules, which essentially say "when the user requests URL x, pretend they requested URL y instead".
Server-side code that acts as a "front controller", looking at the (rewritten) URL that was requested, and deciding what content to serve.
As a simple example:
The user requests /abc/holidays/spain
An Apache server is configured with RewriteRule /(...)/holidays/(.*) /show-holidays.php?site=$1&destination=$2 so expands it to /show-holidays.php?site=abc&destination=spain
The show-holidays.php script looks at the parameter $_GET['site'] and loads the configuration for sub-site "abc"
It then looks at $_GET['destination'] and loads the appropriate content
The output of the PHP script is sent back to the user
If the user requests /def/holidays/portugal, they will get different content, but the same PHP script will generate it
Both the rewrite rules and the server-side script can be as simple or as complex as you like - some sites have a single PHP script which accepts all responses, looks at the real URL that was requested, and decides what to do; others have a long list of mappings from URLs to specific PHP scripts.
I've been reading about redirection, and how it can affect (or not if done properly) SEO.
I'm changing my website's content platform from Drupal to a PHP custom made code.
In my current site I have two links that point to the same link like this:
.../node/123
.../my-node-title
Mainly because Drupal allows you to create a custom-made links, so every article has a default one (node/123) and the custom-made one (/my-node-title).
My question is about what to do in order to prevent losing any SEO that each link may have.
In the new website all articles are structured like this: content.php?id=123
I've stored in the database the custom-made link of every article.
Instead of doing a 301 redirect I'm redirecting all links that do not exist to be redirected to redirect.php page to process the request. There I take the string from the link, look for it in the database and redirect the user.
The process is like this:
in .htaccess file:
RewriteRule ^.*$ ./redirect.php
In redirect.php:
I grab the $_SERVER['REQUEST_URI'] and using explode() I get the last part of the link (ie. my-node-title), look for it in the database and grab the ID of the article (ie. 123) and save it in a $link variable.
Then I use header() function and do the redirect: header('Location: '.$link);
So, people still click on .../my-node-title but when the article loads at the navigation bar appears /content.php?id=123
I would like to know your comments about this solution. I know that with SEO there are not fixed rules, or certainty in anything, but I would like to know if what am I doing is acceptable. Thanks!
Your SEO strategy should not only focus on discoverability of your pages, but also take proper UX into account. Having a user follow /some-link/, and then landing on /index.php?page_id=123 may disorient them.
As for saving your ranking, a 302 redirect (which is what the 'Location' header does in PHP), will not affect PageRank, according to Google. I have no information on how it might adversely affect other ranking signals. You would probably do good to specify a canonical URL for all distinct links that point to the same resource.
Also, be aware that your algorithm won't work, if query parameters are present. You might also want to look at properly handling optional trailing slashes.
Ideally, in my opinion, you would want to provide consistent URLs to the outside world, without any need for redirection. Your URL handling would then internally resolve them to their respective resources, serving the canonical URL on every page load.
I have http://mysite.com/index.php.
And a sub menu
home => http://mysite.com/index.php
about us => http://mysite.com/about.us.php
products => http://mysite.com/products.php
But i want http://mysite.com/index.php to process every request, and just change the content using Ajax request. This way, the site only loads the content part, and is much faster and easy to navigate.
The problem here is SEO, because the only URL google will see is http://mysite.com/index.php and I would like to associate http://mysite.com/about-us to the About Us content, http://mysite.com/product to the Products content, etc.
I know I can do this with PHP just reading the URL and writing the Ajax on the fly, but doing so the whole page is going to be reloaded every time.
Is there a way to do this without reloading the whole page?
What I think I need is to have a regular anchor in the submenu, for exampel pointing to "http://mysite.com/contact-us" but when clicked, instead of opening this page, process the Ajax request.
And if this is possible, Google is going to see this as black hat probably, right?
Regards
Alex
HERE THERE IS A SOLUTION:
window.history.pushState(data, title, url)
Here Rob explains how it works, and you have a working example:
http://moz.com/blog/create-crawlable-link-friendly-ajax-websites-using-pushstate
you can't change the URL in the address bar without changing the page because to be able to do that I couldlet you visit me at http://www.imhackingyou.com/sucker but change the addressbar to read http://www.bankofamerica.com/login
This is a routing issue, not an AJAX issue.
If you were using another tool (cough ASP.NET MVC cough), you'd just add a route (and I'm hopeful there's a way to do this in PHP) that accepted URLS like
/home
/products
...
and routed them to, say,
/index.php?area=home
/index.php?area=products
This is typically accomplished with a rewrite engine when used outside of a good MVC or RESTful URL system. I use ISAPI Rewrite on IIS, but if you're working on the LAMP stack, I think Apache provides a module that provides the same capabilities. (Google .htaccess )
WARNING: RANT FOLLOWS
And, for what it's worth,
Avoid trying to write your entire application in JavaScript. The server's there for a reason. Part of your job as a web developer is to absorb as much of the work onto your server as possible. Browser performance and compatibility issues will drive you mad when you try to do everything on the client.
Avoiding postbacks makes sense in a lot of circumstances, but it's not a silver bullet that you should try to apply to every page. Usually it makes sense to load a new page when a link is clicked. It's what the user expects, it's more stable (since most of the infrastructure required is server-side) and it's not slower than an AJAX request to retrieve the same thing.
Rules:
NEVER break the back button. Without careful planning, most AJAX apps break this rule.
See rule #1.
This sounds like it should be accomplished with a rewrite engine, but assuming that you have a good reason to use AJAX, you can change urls with javascript by modifying the portion after the hash, or better yet, the hashbang:
window.location.hash = "#!about-us";
http://mysite.com/
http://mysite.com/#!about-us
http://mysite.com/#!products
For more info on the hashbang from an SEO perspective, check out http://www.seomoz.org/blog/how-to-allow-google-to-crawl-ajax-content
How does Shopify do it then? Go to their website, click on the Features link and you'll see the URL says:
http://www.shopify.com/tour/sell-online
Then click on any of the sub links and you'll see that the address in the URl changes without using a hash but there is no page flip.
I don't think they are using ajax to change the content because it all appears to be included in hidden divs on the page, but regardless, you can apparently change the URL using client side tricks.
I have a PHP website based on codeigniter. It uses Mode View Controller and has articles. Each article has id and is displayed by Articles controller. Once an article is displayed the url looks like http://localhost/ci/articles/show_article/245. Now the problem is any one can enter number like 246 123 222 and view the articles at random. am not comfortable with this. I want readers to go the way things are organized in the site and want to stop them from directly accessing the articles from URL.
How can this be achieved in PHP / codeigniter.??
This cannot be done. You cannot control what a user types into the web browser.
You can't control user outside the browser area, and if you could. you should not.
Alternatively, you could use encoded article Ids by your own pattern to make it unpredictable. when these encoded article ids are received, decode them back and show the articles accordingly.
It's impossible to do this, and there's also no reason that you should be uncomfortable with it. You can't prevent client-side requests. I think anyone trying to use your site properly (assuming it is set up properly) won't try to go through articles out of order.
If you absolutely must, what you can do is something like set a _SESSION flag for what articles they have visited and if they try to get to one out of order, redirect them.
I have a PHP system containing user-generated pages, arranged in a complex and non-uniform hierarchy. Pages are created by users, and some pages have sub-pages etc.
I have been asked to add a shortened-url system. So any page, at any point in the hierarchy, can be accessed via domain.com/XXXX where XXXX can be anything - we are not interested in SEO here, the reasoning behind this is its a very social-media driven project, and we would like our users to be able to tweet/other the url of any page they like.
I expect something like; we start on AAAA and head towards ZZZZ as each page is created. Each of these slugs would be stored in the database alongside the actual url eg domain.com/projects.php?p=32
I know mod-rewrite enough to convert domain.com/XXXX into domain.com/index.php?slug=XXXX, but where to go from there leaves me a little stumped. index.php can do the database lookup and header() the user to the actual url, but the slug-url needs to stay in the address bar.
Would using an iframe in index.php be a terrible idea?
I hope thats clear, thanks for reading!
If you used the [R=301] directive at the end of an .htaccess rewrite rule, it will act as a redirect. Meaning if you go to domain.com/XXXX it will show domain.com/index.php?slug=XXXX in the address bar. Is that the behavior you're trying to accomplish?
Also, I wouldn't use a header(), I'd make your index page be the processing page. Either that, or use an include() method instead.
I think using an iframe is a terrible idea, and will lead to a brittle site.
Is there any reason why index.php can't act as a front controller, so instead of redirecting it just shows the page? You should just be able to include the page.
Alternatively, could you not rewrite domain.com/XXXX to domain.com/projects.php?slug=XXXX, and do a slug->p conversion at the top of projects.php? Then the conversion would just need to record slugs and page ids, rather than slugs and full URLs.