Q&A: Inside Dartmouth College's Shift to a Product-Focused Web Ecosystem

Key Insights:

• One size doesn’t fit all: Dartmouth uses three CMS platforms—Drupal, WordPress, and Modern Campus—each serving a distinct role based on the needs, complexity, and lifespan of the site.

• From project to product mindset: The web team embraces an iterative, product-based approach to digital development with weekly releases, prioritizing long-term platform sustainability over big-bang redesigns.

• Decentralized content, centralized support: While content ownership is distributed across departments, Web Services maintains platform infrastructure and provides optional SEO, analytics, and training support.

• Smart SEO, stitch by stitch: Dartmouth is taking a long-tail approach to search optimization by focusing on niche topics and department-level content instead of broad, high-volume keywords.

• High-impact enhancements: Recent wins include a dynamic, student-facing dining site and a custom-built communications platform powering Dartmouth’s daily internal email digest.

You have sites on Drupal, Wordpress, and Modern Campus. Tell me about how that breaks down. How do you decide what CMS makes sense for each site? Why does this combo work for you?

Drupal Platforms
We actually have two Drupal platforms currently - Drupal 7 and Drupal 10. Our Drupal 7 sites are on the platform we call DCRS - Dartmouth Content Repository System, which launched almost ten years ago, and allows for extensive content sharing between sites.

We started launching Drupal 10 sites in January of this year. The new sites are a lot more flexible than the previous Drupal 7 sites because they are componentized. They still have content sharing functionality. We looked at what things were shared on D7 sites and found a handful of things were actively shared, including news, people profiles, and policies. We built a new repo focused on those things, which takes some of the complexity out of the previous repo.

We use Drupal for academic departments, centers, and administrative sites, as well as our home site. We are actively moving sites from D7 to D10. We have a support contract with an agency that does our D7 security updates, so that takes some of the time pressure off. I expect it will probably take another year and a half to move all D7 sites to D10.

Wordpress
The majority of our sites are actually in Wordpress, but they are secondary. No one is getting called in the middle of the night if Wordpress goes down. Sites.dartmouth.edu is a DIY platform for labs, personal sites, clubs, and other things that might not have as much longevity as a department site. A lot of conference sites are built on this platform. We call it DIY, but we put in maybe up to ten hours of help for faculty.

Journeys is our Wordpress student platform. A site is automatically spun up for every student. The templates are mostly the same (as sites.dartmouth.edu), although slightly different, and driven by faculty needs for student academic purposes.

Modern Campus
Lastly we have Modern Campus, which is a legacy platform for us. It’s what we used before Drupal, and some sites are still on it. The sites here tend to be much simpler, needing text and maybe some images online. We are no longer building new sites on Modern Campus, so over time we’ll migrate completely off of it. In the meantime, it takes very little effort from us and is easy to keep it running.

You used to have a tiered service approach for your Drupal sites. Is that still the case?

No. The customization requests were so unique that it was hard to really fit them in a sort of structure like that. What we do now is the platform is free. If you have a small request, we’ll try to do it but you might wait six months for it. If you want something sooner or larger, then it takes budget.

Sometimes we’ll try to do the larger requests in house. I’ll ask the dev team. If they think something is interesting, we’ll do it. If they aren’t interested, and there is budget, it goes to OHO.
 

Many organizations are embracing a more iterative approach to website design. Instead of the big redesign and migration every 5-10 years, they are making smaller, more frequent updates. Is this how your team is approaching things?

Very much so. I call Ben Morgan, our associate director of web services, a product manager specifically because of this approach. And this approach is holding up because the homesite is four, maybe five years old design wise, and it’s still holding up well.

We do releases every week. We have a pretty active release schedule. It might be only a handful of updates but we are actively rolling out updates across the Drupal platforms. A release might include bug fixes, security updates, or enhancements. Our current design is going to have some longevity, partially because it’s componentized. We have the ability to add components to the system, which will give it a longer life span.

Ben meets with the owners of complex sites weekly to hear about their feature requests. He also meets weekly with Chrissy Pearson, our associate directory of content strategy, who owns the rest of the platform. She keeps a list of enhancement requests that she hears from users. And then Ben takes all these requests and figures out what is the highest priority across the platform each week.

Our Admissions team is working directly with OHO, so they are actively doing enhancement for their site. OHO is building the Admissions enhancements within our platform and then we’re releasing them.
 

How do you get your budget for platform development: through capital or operating costs?

I’m in conversation with finance to try to put aside a reserve that would be separate from the annual budget. What finance has told me is they can deal with a lot as long as they’re not surprised. So if you’re guessing it’s going to cost a million dollars to do a redesign every five years, can we for example put aside $200,000 a year for five years so the money is there when we need it? I don’t know if it’s going to work.

You could do a capital project for a significant update to a whole bunch of components, but then you might be able to bucket things into a “project” even though it’s still kind of an evolution. Like a major home renovation where you’re not tearing things down to the studs, but you are adding on.

A lot of people think of these things as one big project and don’t think of them as a product. They think, “Oh great, I’m done, I did the website redesign.” These things are not ever done, as everyone who's been doing these things a while knows. It does everyone a disservice to think of things as projects instead of products. It’s much closer to building a building. After it’s built, you have to keep the heat on, and you have to replace the window that gets broken.
 

Do you provide any kind of ongoing support for clients post-launch? What kinds of challenges do they run into after you turn the site over to them to maintain?

We do train all editors on the new system. We also offer optional training on SiteImprove so they can use it to look at broken linkens and basic analytics work.

We’ve started rolling out support for SEO. If they want to have things targeted at specific audiences and subjects, we use BrightEdge, so we’ll help them start looking at targeted content.

I have a theory that the best way for Dartmouth to improve its SEO at this point is improvement by 1000 stitches. Instead of targeting “Dartmouth,” you target “research on octopuses” or something that is happening at Dartmouth, and it helps raise the total engagement. There are so many different things happening here. We’re never going to rank for “climate change,” but maybe a specific component of climate change we could rank really well for – and we have thousands of those across the institution.

But we’re working with very few groups on this. Many people don’t prioritize the digital space. They just don’t have the time. Some departments really do prioritize it and clearly put in work and really think about it. And other people are like, we have a site, we’re good.

That’s the fundamental challenge: because we don’t own any of the content, it’s really up to individual departments to decide to put resources behind it or not.
 

What’s something that you’ve done in the last couple of years that you feel has had the biggest impact?

We decided to take on a complex project that’s really more like a web app: the dining services menu site. It was our second D10 site and is one of our highest trafficked sites. It was really cool to do something for students, and the team was super excited to do it. We did a bunch of research around it. And it’s such an upgrade from what they had previously, so it’s a stark contrast. It made a big impact from a student standpoint. And it’s one of our biggest touchpoints for students, since most of our sites are externally focused.

Another project that has had a big impact is the system for Vox, our daily news email digest. Faculty and staff can submit updates that go in the daily email. Our previous system was so old that only one person knew anything about the backend and even he didn’t want to touch it. It was at least 25 years old. Now it’s on a modern platform, with the front end all based in Drupal, and some complex business rules.

When you submit an announcement, you can choose different groups of people who will receive it, like all students, undergrads only, graduate students, and so on. Each group gets individualized email messages. There are twelve different groups, but that generally results in 40-45 different email messages each day. A student might also be a staff member, for example, so they get an email that has just the announcements marked for students and staff members.

We use Hubspot for sending the emails. Hubspot has two different email services: marketing and transactional. We’re using the transactional version as an internal email server. Drupal creates the lists and sends the info to Hubspot and we send it out from there.
 

At a Glance: Dartmouth College Enterprise Web Ecosystem