+ Start a Discussion
SuyogSuyog 

Maintaining URLs on Site.com

We have different pages that already exist and they have URLs as "www.abc.com/xyz.html". But on Site.com, since the content is dynamically generated, the URL is now "https://sitepreview.na2.force.com/page?id=a004000000dahmEUAA" where the content of the page is generated based on the id.

 

When the site will go live with existing domain, would it have URL as "www.abc.com/page?id=a004000000dahmEUAA"?

 

Is there any way to ensure that the new URLs generated when the site goes live be same as the existing URLs for the site so that search engines can list them?

laura.mckevitt@bakertilly.comlaura.mckevitt@bakertilly.com

Suyog,

 

We have noticed this as well and raised the issue with Salesforce as a bug - after the latest release, it appears that the site id and version are appearing at the end of the URL of all the assets that reside within the Site (not the pages themselves however). 

 

You should also raise a case with Salesforce on this issue.

 

Laura

Ryan-GuestRyan-Guest

Take a look at using URL Redirects - this way you can preserve your search engine rankings

 

https://login.salesforce.com/help/doc/en/siteforce_redirects.htm

laura.mckevitt@bakertilly.comlaura.mckevitt@bakertilly.com

Ryan,

 

This is helpful as a workaround - but I'm not sure this resolves the issue of Siteforce automatically adding a site id and version number at the end of the URLs.

 

Laura

SuyogSuyog

Thanks.

 

As per my understanding URL redirects works only for relative URLs. This means both the old page and the new page should be in Site.com.

But we have existing site hosted on some other server which we have completely migrated to Site.com and we want to preserve the search engine ranking for the pages which already exist there.

 

Is there any way to implement URL redirects across domains?

 

Please correct my understanding.

Ryan-GuestRyan-Guest

Laura - ya this would solve Suyog's issue, but not yours.

 

In your case, doesn't the URL still work if you don't add the site id and version number?

laura.mckevitt@bakertilly.comlaura.mckevitt@bakertilly.com

The article that Ryan posted within the Help section discusses how to do this within Site.com:

 

 

Creating URL Redirects in Site.com

 

If you move or reorganize pages in your site, search engines may have trouble finding the new page locations. To avoid this, set up URL redirects to inform users and search engines that site content has moved.
Available for purchase in: Enterprise and Unlimited Editions

Available (with limitations) in: Developer Edition


User Permissions Needed
To build, edit, and manage Site.com sites:Site.com Publisher User field enabled on the user detail page

AND

Publisher or Designer role assigned at the site level

You can use URL redirects to:
  • Maintain search engine ranking. For example, if you change a page’s name from “Gadgets” to “Widgets,” creating a redirect rule from /Gadgets to /Widgets lets you restructure the site without affecting your page ranking.
  • Make URLs more readable and memorable. For example, site visitors will find long or numeric page names, such as/widget65AD890004ab9923, difficult to remember. Instead, you can provide them with a short, friendly URL, such as /widget, and create an alias that redirects to the correct page when the user uses the short URL alias.
  • Assist with migration from another system to Site.com if you’re still using the same domain. For example, if your old site ran on PHP, you can create a redirection rule from an old page, such as /index.php, to a new page in Site.com, such as /myNewPage.

To assign a redirect to a site page:

  1. On the Overview tab, click Site Configuration | URL Redirects.
  2. Click Create a Redirect.
  3. Specify the Redirect type:Option Description
    Permanent (301)Select this option if you want users and search engines to update the URL in their systems when visiting the page. Users visiting a page redirected with this type are sent seamlessly to the new page. Using a permanent redirect ensures that your URLs retain their search engine popularity ratings, and that search engines index the new page and remove the obsolete source URL from their indexes.
    Temporary (302)Select this option if you want users and search engines to keep using the original URL for the page. Search engines interpret a 302 redirect as one that could change again at any time, and though they index and serve up the content on the new target page, they also keep the source URL in their indexes.
    AliasSelect this option if you don’t want the URL to change in the user’s browser, but you want to redirect to a different page. Search engines won’t be aware of the change or update their records.

    Alias redirects only work when you redirect from one Site.com page to another. You can’t create an alias to an external address.

  4. Specify the former page location in the Redirect from field.
    • The page location must be a relative URL.
    • The page can have any valid extension type, such as .html or .php, and can contain parameters. Parameter order is irrelevant.
    • The URL can’t contain anchors, such as /siteprefix/page.html#target.
    • You can create just one redirection rule from a particular URL. If you create a new rule with the same Redirect From information, the old rule is overwritten.
  5. Specify the new page location in the Redirect to field. This can be a relative URL or a fully-qualified URL with anhttp:// or https:// prefix. Unlike pages you’re redirecting from, pages you’re redirecting to can contain anchors.
  6. To immediately enable the redirection rule, ensure Active is selected. To enable it at a later stage, deselect the property.
  7. Click Save.
The URL Redirects section displays all URL redirection rules you've created for your site.
  • Edit an assigned redirect rule by clicking Actions | Edit Redirect.
  • Delete a redirect rule by clicking Actions | Delete Redirect.

 

laura.mckevitt@bakertilly.comlaura.mckevitt@bakertilly.com

Ryan, 

 

My response was based on his first question, and yes it does display the internal id and version, but only for assets within the site itself (not pages on our end). It performs functionally no different however, you are correct.

 

It does still work, but Siteforce should not tag onto the end of the asset's URL with internal information such as a Site ID and a Version Number. This should not be visible to others and is not a matter of functionality.

 

Thanks,

 

Laura