Tech Wireless

Feel the future

How to Get Your Website Indexed by Google

 

Many people said that getting your new website to show up on Google takes a month or more. Not again. Using Google’s very own new technology, you can do it in about 3 days or less.

Steps

  1. Make sure that your website is ready (i.e. no broken links, has enough unique contents, etc). Optimize your website for keywords that are highly related with your website content.
  2. Create a sitemap file for your website. Sitemap file is a formatted file with an XML extension. It contains the URLs for all of your pages in your website. You can use free online or offline tools available to generate your sitemap file.
  3. Upload the sitemap file to your website root directory.
  4. Go to Google Sitemaps website and log in using your Google account. Create if you don’t have one. It is free.
  5. Type your website full URL in the “Add Site” field on the top of the Google Sitemap page and click OK.
  6. Click the “Add Sitemap” link on the right of your website name.
  7. Choose “General Web Sitemap ” on the “Choose Type” option list. Check all the checkboxes provided.
  8. Type your full sitemap URL in the provided field and click “Add Web Sitemap” button.
  9. Wait for about 2 or 3 days. Check Google by typing your website name in the search box. If it shows up in the result, it means that Google has indexed your website.

Tips

  • Always use specific keywords and not a broad one (such as “fashion”, “internet”,”sports”, etc) in optimizing your website.
  • Generate and resubmit your sitemap file everytime you make changes to your website. By resubmitting, you can always tell Google about your changes. Consult the Google Sitemaps help for more information of how to do this.
  • Google Sitemaps provides a number of statistics about your website. You can use it to know how Google and people find your site. It is very useful to help you improve your website content. Consult the Google Sitemaps help for more information about this.
  • After getting indexed by Google, increase the number of websites that link to your website and create more unique content to improve your website rankings.
  • Make sure this is at the top of your coding on each page <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

Warnings

  • This method is only used to tell Google that your website exists and not to gain top rankings. To get a top rankings, especially on Google, a considerable amount of effort is indeed required.
  • Google Sitemaps technology is still in development stage. So, expect errors to happen or expect that your website not getting indexed in 3 days. However, I haven’t had any difficulties using them. My new sites always getting indexed by Google in less than 3 days.

December 7, 2007 Posted by Waqas Sadiq | hosting | | No Comments Yet

Tips On Using SubDomain

Points to consider before using subdomains

Subdomain makes the URLs shorter and nicer. It allows website owners to categorize the
content of the website. It also helps in improving the search engine rankings as most of the search engines treat the subdomain as a separate website address. However, there are certain things to consider before setting up subdomains for your website.

  1. Many web hosting providers do not provide subdomains in their hosting packages. If you have subdomain and want to move your site, you have to choose one which supports subdomains.
  2. Most web hosts charge extra for subdomain setup and maintenance.
  3. If you use cookies in your website, a cookie set from a subdomain cannot be read from the main domain and vice versa because of the security association feature tied to the domain which set it. This is also true for session cookies, where, if the user is logged in on the main site, and then moves to a subdomain, the subdomain site will not be able to access the same session cookie, and will assign a new session (hence forcing the user to login again). However, session persistence across subdomains can be maintained by implementing URL rewriting instead of session cookies.
  4. Your website stats will often not include the statistics of the subdomains. Therefore, you have to setup separate statistics for your subdomains. One of the advantages of using subdomain is that the website can be broken down into smaller pieces without losing the brand image associated with the domain name. The subdomains can be hosted on separate servers in order to reduce the burden on the main domain hosting server.

Sharing cookies among all subdomains

As explained earlier, cookies are not shared among subdomains or between the domain
and the subdomain. In order to set cookies accessible by all subdomains, use the
following techniques:

  1. While writing the cookie, set the cookie domain to “.domain.ext” so that it applies to all subdomains.
  2. If the cookie domain is set to “.domain.ext”, it will not be accessible by a user who types in the address without the www before the domain (i.e. http://domain.ext). Therefore, redirect all requests without www to http://www.domain.ext.

There are some reported problems with the above approach. It is safe to set the default cookie with no domain specified and then set another one with domain as “.domain.ext”. In this case there is no need for the redirects.

However, remember that session cookies are set by the web server software and you may not have control over how the cookie domain is set.

November 21, 2007 Posted by Waqas Sadiq | hosting | | No Comments Yet

A ten-minute guide to setting up a WAP site

Intended audience

This article describes, very briefly, the steps involved in providing WML pages to mobile devices, in particular WAP-enabled mobile phones. It assumes that reader is already familiar with HTTP, HTML, and Web server operation, but knows nothing about WML or WAP protocols. The article does not attempt to describe WML, but does provide a simple example.

Basic principles

Viewers for WAP content are often called microbrowsers. Microbrowsers are found in WAP-enabled mobile phones, and some PDAs, among other things. If you are familiar with Web servers, then you may be reassured to know that at least one thing is the same for WAP services: the HTTP protocol. WAP microbrowsers use exactly the same HTTP protocol for exchanging pages as ordinary Web servers and Web browsers do. So, although you could pay a good deal of money for a `WAP server’ for your enterprise, in fact any Web server will do perfectly well; Apache, for example. Of course, some WAP server products offer a good deal more than basic HTTP support, such as portal services and content management. However, if you just want to create pages of data and make then available to WAP phones, all you need is a Web server. In the same way that Web browsers expect their pages to be delivered in HTML format, WAP microbrowsers expect content in WML format. WML (WAP Markup Language) is simply XML, formatted according to a particular schema. Unlike traditional HTML, which only has a passing resemblance to XML, WML is true XML. It can be processed by a validating parser, and ill-formed content rejected. In principle, WML’s stricter syntax rules suggest that there should be less inter-browser variability in formatting than is the case for HTML, but my experience has not borne this out. You should consider testing your WML pages with more than one browser if you want good coverage.

A significant difference between WML and HTML is that a WML document can contain multiple pages (cards, in WAP jargon). When the browser loads the WML document, it will usually display the first page. This will generally contain links to the other pages. HTML, of course, has a single-page format. If you want to display multiple pages, you need multiple HTML files. The difference is for a very good reason. A WAP phone has to establish a dial-up session for each request, and this takes time. It is more convenient, therefore, if the browser can retrieve a set of pages at the same time. WML provides the concept of cards to enable pages to be grouped. Because a WML file contains cards, you will see the phrase `WML deck’ used to mean a WML file. This is a trendy piece of jargon, and `deck’ means nothing more than `file’ in this context.

When a WAP-enabled phone is asked to display a WML page, it needs a URL. The URL has the same format, and meaning, as the URL in any ordinary Web browser. When it has the URL, the WAP phone will dial up a WAP gateway, and then issue an HTTP request for that URL, usually over the public Internet. The gateway collects the response, and returns it to the browser. The browser then hangs up (either immediately, or after a short delay).

The following sections describe step-by-step what you need to do to get a very simple WML page available to WAP phones.

Step 1: get a web server running

Unless you are going to run your own WAP gateway, that is, software that accepts incoming phone calls and relays them to a Web server, you need a web server on the public Internet. You don’t need exclusive access to the server; if your existing web site is hosted by an ISP, even a free ISP, it should be possible to host WAP content as well. However, the Web server must deliver the correct content-type header when the browser requests WML content. With the Apache Web server, this mapping from file extensions to content types usually lives in /etc/mime.types, although you can also use an AddType directive in httpd.conf. Other servers have other conventions. As a miniumum, you need to ensure that the file extension .wml, or whatever else you intend to use for your WML pages, maps onto the content type text/vnd.wap.wml. There are other content type mappings you might need, but this one is a minimum. The problem with using any kind of shared Web server, either paid for or not, is that you may not be able to influence the mappings of file extensions onto content types. However, all modern Apache versions have WAP mappings in the default mime.types file, so if your ISP uses Apache you should have no problems.
If you intend to deliver Java applications to suitably-equipped devices via your WML pages, then you need to make sure that the appropriate content types are mapped. This is not a default in Apache, so you’ll need to do it yourself. Add the following lines to httpd.conf:

AddType text/vnd.sun.j2me.app-descriptor jad
AddType application/java-archive jar

Of course, other Web servers will require this configuration as well, using whatever technique they support. It is not difficult, in principle, to run your own WAP gateway, and this may be useful for a company that wants to provide a private resource to its employees. A WAP gateway is nothing more than a modem and a PPP server. However, to make use of a private gateway requires some reconfiguration of the browser’s communications settings, and not every WAP phone user will be happy doing this reconfiguration.

Step 2: create a WML page

This is not the place for a tutorial on WML; in any case, there are plenty of those on the Web. Suffice it to say that you need a WML page to test your WAP service, and if this is your first time using WML you should probably make it as simply as possible. The listing below shows a very simply example: it is a deck of two cards, with links between the cards and a bit of text.

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="test1" title="KB WAP test p1">
<p>
Test page 1
</p>
<p>
<a href="#test2">Next page</a>
</p>
</card>
<card id="test2" title="KB WAP test p2">
<p>
Test page 2
</p>
<p>
<a href="#test1">Prev page</a>
</p>
</card>
</wml>

Step 3: upload and test with an emulator

Put you WML page(s) into any convenient place on your Web site. If you are planning to build a large WAP site, you would probably want to set up a separate site or area of your site, but this isn’t essential. When you request the WML page with a browser, you will specify its URL just as for an HTML page. I strongly recommend testing the WML pages, and the Web server, using a WAP browser emulator. Then if things don’t go according to plan when you request the page using a microbrowser, you can at least be reasonably confident that the problem does not lie with your Web server or its configuration. I use Deck-it from PyWeb; this is available free of charge for Linux and Windows systems. All you have to do is run Deck-it, and enter the URL of your WML page.

One word of warning, however: do not assume that because you can fetch and display your content using an emulator, you will be able to do so using a real microbrowser. Deck-it, and most other emulators, are far more tolerant of badly-formed WML, and incorrect response headers, than real microbrowsers and WAP gateways are. Remember that a microbrowser is very limited in its memory footprint, so it will parse the WML in a fairly prescriptive way. If your WML isn’t up to par, not only will you not get a display, but you won’t even get a helpful message. Error messages like `bad response from origin server’ may simply mean that your WML is syntactically incorrect. It’s worth getting hold of a WML validator, the stricter the better. Alternatively, there is a public WML validation service at HTMLHelp.

Step 4: test with a microbrowser

If you are using a WAP-enabled phone or PDA, all you need do is start the browser, and enter the URL. On Nokia phones, for example: select `Services’ from the main menu, scroll down to `Go to address’, then enter the URL. With a bit of luck, you should get the same display on the screen that you did on the emulator, or at least something similar. As mentioned before, don’t assume that because an error message looks horribly technical, that it isn’t a simple error like missing a closing tag in the WML.
Be aware that some low-cost mobile phone services restrict phones to getting WAP content from the service provider’s hosts. If you have such a phone service, it will be difficult to enter the URL of your WML site. Nearly all mobile phones allow the communications settings to be changed, and the limition can be overcome by pointing the phone at a different WAP gateway. Of course, you may have to pay for the use of such a service.

Providing Java applications to WAP devices

This is not the place to describe how to create Java applications for mobile devices; I assume that you have available the JAR and/or JAD files that implement the desired application. In brief, the JAR file contains Java executable code in compressed format, while the JAD file is a text file that provides information about the application. Not all WAP devices require JAD files, but most do, so it’s as well to provide them. Mobile devices that support Java applications (known as midlets) generally provide a number of ways for the user to get applications onto the device. For WAP devices, an interesting approach is to make the applications available for download using WAP protocols. In WAP jargon this is called over the air (OTA) installation. Devices that don’t support OTA will use a cable, or bluetooth, or infra-red communication. These installation methods are not relevant to the present discussion, as they are proprietary and not covered by WAP standards. I will concentrate here on making Java applications available OTA.

WAP phones that support OTA installation normally provide the user with at least one of the following methods of download.

  • The user follows a link in the browser to a JAD or JAR file (JAD is more widely supported). The device downloads the JAD, locates the corresponding JAR, downloads the JAR, and installs it. Normally the user gets asked at some point if it is OK to install.
  • The user tells the phone to install an application, and provides a URL. The URL links to a WML page that contains a list of hyperlinks to JAD or JAR files. The device extracts the hyperlink text from the page, and presents a menu of application choices. When the user selects an application, the device downloads the corresponding JAD and JAR file, and installs the application.

You can support both these methods using the same WML page: just provide a page titled `Application downloads’, or whatever, and provide in the WML a list of hyperlinks like this:

<a href="myhost://myurl/app1.jad">Application 1</a>
<a href="myhost://myurl/app2.jad">Application 2</a>
...etc

The use of absolute URLs in the href tags is necessary, for maximum portability. Mobile devices don’t necessarily assume that a Java application can be obtained from the same directory as the WML file that references it, even if that is the case. In other words, even if your JAD and JAR files are in the same directory as the WML files, you’ll still need absolute URLs to the JAD files.

November 21, 2007 Posted by Waqas Sadiq | hosting, wap | | 5 Comments

Subdomain Configuration

Subdomain Configuration
A subdomain configuration is very similar to a domain name configuration. The only difference is that the subdomain entry is tied to the corresponding domain name lookup. A request for the subdomain (e.g. http://techwireless.wordpress.com) will be routed to a DNS server containing the DNS information for the parent domain (wordpress.com). Once the DNS record for the subdomain is resolved to a particular IP address, the request is sent to the web server listening on that IP address. The web server can now delegate the request to the particular website based on the subdomain name in the host header of the request object. Various combinations of subdomain configurations are possible by using DNS server entries and web server application setup for load distribution, application isolation or security purposes.

Subdomain Setup on DNS server
The forward lookup zone of the parent domain in the DNS server should contain a pointer to the sub domain using either an alias (CNAME), a hostname (A) or a mail enchanger (MX) entry. The alias (CNAME) record is used for a subdomain if the subdomain points to a website running on the same web server at the same IP address as the parent domain website. A new hostname (A) record is used if the subdomain points to a different web server, or to the same web server listening on a different IP address (as in the case of load distribution).

Alias (CNAME) Setup: An alias points the subdomain to the same web server, which hosts the website for the parent domain. The canonical names (CNAMES) are added for each of the subdomains as shown below. Once the subdomain is resolved to the IP address of the web server, the web server can route the request to a different website (see section on web server setup below). Note that an alias for www is setup as a subdomain by default by most hosting companies, so that requests to www.domain.com is sent to the same website that handles the requests for domain.com.

www IN CNAME domain.com.
subdomain1 IN CNAME domain.com.
subdomain2 IN CNAME domain.com.

Address (A) Record Setup: A hostname DNS entry is required if the subdomain is pointing to a different IP address than that set for the domain name. Add the address (A) records to the forward lookup zone of the parent domain and associate the address records with the IP addresses of the web servers, which will handle the requests for the subdomain.

subdomain1 IN A 123.2.33.45.
subdomain2 IN A 123.2.33.46.

Mail Exchanger (MX) Setup: The mail exchanger subdomain configuration is required if an email server is setup to handle the subdomain mail accounts. For example, an email address like joe@arts.myschool.edu will require a subdomain setup for resolving the mail server for arts.myschool.edu. The setup is similar to the CNAME setup but with MX records.

subdomain1 IN MX 10 subdomain1.domain.com.
subdomain2 IN MX 10 subdomain2.domain.com.

Note: If the sub-domain is configured on another DNS name server, a Name Server (NS) record has to be created for the sub-domain on the corresponding domain name DNS server, so that it can delegate the sub-domain lookup to the other name servers. Using different name servers can eliminate security issues in cases where the sub-domains are maintained by separate administrators. However, the lookup carries an additional overhead.

Configuring the web server for sub-domains
Once the DNS server is setup to send the request for the sub-domain to the corresponding IP address, the work of the web server begins. The web server needs to be configured appropriately to handle the request for the sub-domain based on either the IP address or the host header entry. Host headers are commonly used by web servers to host multiple domains or sub-domains on one IP address.

Microsoft Windows IIS : In case of Internet Information Server (IIS), create a new web site for the subdomain using the IIS Manager, and add the sub-domain (e.g. subdomain.domain.com) as a new host header value listening to the same IP address as specified in the DNS entry. The port is set to 80 (the default for http requests). The host header can be added by clicking on the advanced tab next to the IP address configuration for that web site application. If the subdomain points to a subdirectory of the web site for the domain, then set the home directory for the subdomain web site to the subdirectory. For example, if the domain.com points to C:\Inetpub\wwwroot\ and the subdomain needs to be setup for C:\Inetpub\wwwroot\subdomain, then the directory for the subdomain website should be set to C:\Inetpub\wwwroot\subdomain.

Apache Web Server : In case of Apache web server, the subdomain is configured by virtual host entries in httpd.conf as shown below.

Listen 80
NameVirtualHost *

<VirtualHost *>
ServerName www.domain.com
DocumentRoot /home/httpd/htdocs/
</VirtualHost>

<VirtualHost *>
ServerName subdomain.domain.com
DocumentRoot /home/httpd/htdocs/subdomain/
</VirtualHost>

Conclusion
Sub-domain configuration starts with an entry in the DNS server of the parent domain and the lookup resolves the sub-domain to an IP address of the web server. The web server in turn delegates the requests based on its configuration for the sub-domain. Various sub-domain configurations can be used effectively to distribute the load evenly among available web applications or web servers listening to different IP addresses. The load distribution is achieved by the DNS round robin feature of the BIND. Other uses include application isolation, simpler and professional looking URL, content categorization etc.

November 21, 2007 Posted by Waqas Sadiq | hosting | | No Comments Yet

Introduction to subdomain


What is a subdomain?

A subdomain is the part of the website address before the domain name. For example, the address for WordPress forum is http://techwireless.wordpress.com. Here, techwireless is a subdomain of the domain name techwireless.com. Subdomains are also known as the third level domains or canonical names. A subdomain, unlike a domain name, is not registered anywhere because it is associated with a domain name only. It can be created by the web host on the DNS server. The most commonly used subdomain is www, as in http://www.wordpress.com. However, there is no need to add www in front of the domain name. Similarly, mail server addresses often have mail as the subdomain, as in mail.wordpress.com.

Why are subdomains used?

Subdomains are commonly used to categorize portions of the website. For example, the services offered by WordPress are categorized by their subdomains, such as techwireless.wordpress.com. The benefit is that the subdomain can be easily moved to another server if the category gets very popular.

Subdomains are also used by free webhosting providers to resell web space under their own domain name (e.g. http://techwireless.hostname.com). Each member will have their subdomain, however, they all will still share the domain name of the hosting provider.

The third reason for using a subdomain name is to load balance the web servers for a high traffic website. Multiple web servers are assigned different subdomains like www.sitename.com, www1.sitename.com, www2.sitename.com etc, though each of them contain the same application code. When the request comes from the browser, the load balancing softwares redirects it to one of these servers. DNS load balancing is a simple method of load balancing using subdomains pointing to different IP addresses.

Types of subdomain setup

Subdomain can be setup in different ways, although the subdomain information is stored similarly in the DNS server.

  1. Separate Site: This type of subdomain setup will the have a separate hosting account or hosting location with respect to the domain hosting account. The hosting provider usually assigns new resources (disk space, bandwidth etc.) for this subdomain and charges fees as if it is another hosting account. There is often no way to share common files (such as include files by relative path) between the domain account and subdomain account.
  2. Sub-Directory Pointing: In this case, the subdomain is pointed to a sub-directory of the web root folder. For example, subdomain.domain.ext will point to /account/www/subdomain directory. Essentially, the resources of the domain in this case are shared by the subdomain as well. Usually the hosting provider does not charge additional fees (other than subdomain setup fees). Both the domain and subdomain can also reuse the same common files (such as SSI includes) from the same shared directory location.
  3. Separate Server: This type of configuration is similar to the separate site configuration but hosted on a separate server with a different IP address. In this case the subdomain can reside at a totally different geographical location. The advantage of having a separate server for a subdomain is in load distribution among servers (by separating application functionality) or providing horizontal scaling in case of load balancing between servers (by identical replication of application code on each server).

November 21, 2007 Posted by Waqas Sadiq | hosting | | No Comments Yet