so I just migrated a bunch of my old web sites to .net mvc and turned them loose on the net last week.
I optimized them as best I know how for SEO but I'm noticing that NONE (not a single one!) of my sub pages is being displayed on google...only my home pages.
I created controllers for the products to try and give them plugs for each page.
ex:
http://www.mywidgets.com/widget_to_make_coffee/coffee_making_widgets
ironically, google is still showing some of my sub-pages from the old site, which I have redirecting to the new, but I fear that when it fully updates its index, I will lose that placement and not gain the placement from my new stuff as it's no-where to be found...
is this bad practice? Should I have structured everything off of the home controller?
Should I have structured everything off of the home controller?
No. Something else it's going on.
One of the advantages of ASP.NET MVC is that you can de-couple your routes (URLs) from the logic of your code (models/views/controllers)
The only important thing is that you have something at the old urls passing a 301 redirect to the new urls. Google will fix itself pretty quickly after that.
Depending on how many incoming links you've got, you might end up keeping the redirector up permanently.
Related
I would like some opinions on the following approach to architecting a web application.
A user will navigate to a login page. After logging in, the user will be sent to what I will call a primary page. The idea is to have the primary page contain some common material at the top of the page along with a menu. Below the menu taking up the majority of the page is an IFrame. Each of the menu items, when selected, would load the appropriate page into the IFrame. Here is the main point. The user can navigate through the application using the various menu selections and carry out whatever those selections allow while the primary page remains loaded during the entire session, that is, until the user logs out or closes the browser. This approach does not follow what appears to be the more common paradigm where the browser completely replaces web pages with other web pages as the user navigates through the site. No page stays loaded during the entire session. Is leaving the primary page loaded during the entire session a good idea?
If not, what are the main concerns? Also, can you site any references to a different approach to accomplish the same application-like behavior?
If okay, is there any advantage to using MCV over Web Forms to obtain this behavior?
majority of the page is an IFrame
Iframes are bad. They always have been bad, they always will be. There a dirty hack.
Don't use iframes.
SPA
If you have a good reason not to use actual pages and redirects you can try one of those single page applications that seem to be popular.
I will however remind you that if you rely javascript you basically can't do SEO.
Progressive enhancement
As an aside read up on Progressive Enhancement. You should be doing that.
Partial views
If you like having a large portion of your website static then you can always load partial views over ajax and render them on the client.
Of course because your doing progressive enhancement your doing full page redirects and loads aswell. The partial view rendering on the client is just bells and whistles.
.NET
As for using C# frameworks I would personally recommend Nancy.
If you want to use ASP (god knows why) I guess you can use ASP.NET MVC, sure it's far from optimum but at least it's not ASP.NET webforms
I don't think it's the absolute evil, but your solution does not actually follow the "normal" behaviour of an HTML site, and browsing may be less intuitive.
Users will have problems for bookmarks or using back button, for example.
You will not be able to adapt the menu accoring to the current displayed content (or will have a hell of synchro problems!), for example showing wich section you are in.
The common solution for web is to use a layout, or two-step view pattern (see http://framework.zend.com/manual/en/zend.layout.introduction.html)
I don't know well webforms, but MVC is known as the standard de facto for most web applications and frameworks. It's nice because of the splitting of the roles and the organization it enforces.
I'm pretty new to ASP.NET MVC and I just want ask of this scenario is possible and, if so, could anybody provide any resource links on how to implement it.
Say I have a site that can be accessed from www.mysite.com, can I also have the same site load up through www.mysite2com, www.mysite3.com and so on? effectively providing the ability to run multiple sites from a single code base?
The idea is to have the site content and style sheet change depending on site visited but keep the structure the same.
thank you very much for any help you can provide :)
Kris
Yes, this is possible
http://web.archive.org/web/20100119084358/http://just3ws.wordpress.com/2010/01/03/skinning-your-asp-net-mvc-application-based-on-your-sub-domain
This example uses subdomains of the same domain but nothing stops you from using the same logic and have different images/CSS/paths etc generated based on full HOST/domain name
It's well-past time for The Office's websites to be upgraded and for the main public one, I'm considering migrating the existing .Net 1.1 ugliness up to ASP.Net MVC.
The only real doubt I have is over the fairly extensive work on SEO that has been carried out on the site.
What considerations should I bear in mind regarding SEO when moving from an old webforms site to MVC urls?
If your question is only about URLs, then the answer is that redirecting the old URLs to new ones with a permanent redirect (301) should do the trick - search spiders should update the results to new links without any SEO hit.
There will be other factors to consider as well - e.g. changed HTML structure of pages (I hope you are not going to mimick the output of the old ASP.NET in your new web app :)).
I would take a long hard look at routing. That's going to be the key to getting the SEO working as desired on the URL's. You may also want to have html helpers for formatting the rich url's.
You should consider your old links using either a) standard web forms with routing or b) making a large routing table that handles request for all of those old URLs that have already been cached / scraped by Google, Yahoo, Bing, etc. If, as you say, you already have some good SEO in place, you don't want all of those links to suddenly stop working.
I have an application written in MVC that uses your regular .Net Forms Authentication. There's nothing particularly new or exciting going on with it.
My client has now asked that users be able to log in to the app on the same machine but in different browsers, or different tabs within the same browser. To my mind, he's asking for a scope change to have authentication moved to cookieless instead of its current design.
Not having had any experience with doing this in MVC, I'm curious to know before I get started how much hurt I'm in for by trying this. Are there better ways to do it? What should I consider?
Any advice appreciated.
in different browsers
This should be easy because different browsers do not share cookies.
or different tabs within the same browser
That's a little bit more difficult, because the same cookies are used browser-wide, so there is no difference between the tabs.
You can try adding some authentication token to all links like:
http://site.com/home?token=afdaewdf4393cffjedcifa
http://site.com/account?token=afdaewdf4393cffjedcifa
and so on.
It's relatively easy to have the same parameter in all MVC-generated links, because the same parameter is automatically copied into other links as the user navigates between views (MVC by design).
I really like the way ASP.NET MVC works. I'd love to implement it on all new web projects moving forward, but I hit a snag in a prototype the other day that I really haven't found a good solution for, so I ask you, how would you design an MVC app that doesn't fit the typical REST pattern? As an example, the prototype I was designing would have several pages, but the pages themselves aren't necessarily bound to a domain model. For example, take a simple registration site, which might have the following pages:
/Default.aspx
/Register.aspx
/ThankYou.aspx
Occasionally, such a program might require an admin section to deal with such details as moderating sign ups or reviewing data. In a standard ASP.NET web app, I might add the following
/Admin/Default.aspx
/Admin/ListRegistrations.aspx
/Admin/ViewReports.aspx ...
Would it be an unacceptable deviation from the MVC pattern, in this case, to have two controllers such as:
Home->Index
Home->Register
Home->ThankYou
Admin->Index
Admin->ListRegistrations
Admin->Reports
My frustration with this is compounded by the fact that there is no real solid implementation of subcontrollers and areas yet. I'm aware of the "Areas" prototype put together by Phil Haack, but it's not very mature, and quite frankly, I'm not sure I like the way it's setup, but I don't really know how I'd like to see that work either.
I guess when I think MVC, I tend to think REST as well, and having controller actions that represent pages rather than actual entities or actions doesn't sit right with me. What do you think?
You can always mix ASP.NET Web Forms with MVC.
Just add
routes.IgnoreRoute("Pages/{*path}");
to your routing table and add traditional Web form pages to Pages folder of the application.
One mistake that newcomers to MVC make is to group actions into a controller for display reasons. In your case, instead of grouping the Register and ThankYou actions in with the homepage try separating them out into an AccountController as the MVC team has done in the sample project. You can use routing to set the Url's up however you want for the end-user.
As for your other actions, how about a ReportController? You could then additionally have an AdministrationController whose Index action/view contains links to various admin actions, including those on the ReportController.
Short Version: Group actions into a controller by function, not site navigation.
I usually ditch the "Home" controller as the first thing in a project and replace it with a "Page" controller. I use that one for anything that is "just" a page. Things like "FAQ", "Contact Us", etc. I do this at least partially because the default approach to the Home controller requires a new method being added every time you need even a basic, static page.
In that controller, I only have the one action: Display. That action gives all of those pages the same context object. I actually store the content for those pages in the database with a lookup "slug" and tie it into NVelocity templating, but even just static HTML or NVelocity templates in files would work too.
Anything else, like the others said, gets split into controllers by the "thing" being managed. So, a ReportController, User or AccountController, CartController, etc. Then the actions make much more sense.
When you're talking about listing the registered users, it's actually a list of users, so I'd have a UserController and do /User/Display/Registered/MostRecent or something similar. For the registration itself, /User/Register which would post to /User/SaveRegistration which could, in turn, redirect to /User/DisplayProfile/NewUserID or /Page/Display/Home from there.
You can have as many controllers as makes sense; that layout looks reasonable. Note that routes don't have to map directly to {controller}/{action}, but it keeps things simple. Looks fine to me - except I'd probably have ThankYou as a view - i.e. the Register [GET] perhaps uses a different view to Register [POST]