Creative Project Names Hide the Service and Client Context
Observable evidence: Portfolio cards and detail pages use a brand name, campaign nickname, or abstract concept as the main title while the page gives little searchable context about the service, client type, or problem solved. The page may also repeat that abstract name in the H1 and title metadata without a descriptive companion phrase.
Consequence: A prospect searching for a specific type of website or industry experience has fewer textual signals connecting the project to that need. The work can still persuade someone who already knows the designer, but it has less opportunity to participate in non-branded discovery.
Correction: Keep the creative name if it matters to the portfolio, but pair it with a plain-language descriptor that states the service and client context. The H1 can combine the project name with a useful description rather than forcing either creativity or search clarity to carry the whole page.
Owner: The designer or content owner who controls portfolio naming and page copy.
Verification: Review the rendered page, title metadata, internal anchor text, and search performance for relevant non-branded queries. Confirm that the page still reads naturally to a prospective client and does not become a keyword label.
Heavy Portfolio Media Obscures an Otherwise Strong Experience
Observable evidence: Large hero assets load before critical copy, responsive image variants are missing, below-the-fold media loads immediately, or decorative media competes with the main page content. A legacy build may contain 5MB hero files, a gallery of 12 full-resolution assets, source artwork exported at 4K, a recorded 15-second loading event under constrained conditions, or behavior that was only tested on 4G.
Consequence: Visitors can encounter delayed interaction or content display, especially on mobile or slower connections. Search performance is not determined by a single speed metric, but poor loading behavior can undermine usability and makes the agency's own site a weaker demonstration of production quality.
Correction: Choose efficient formats that preserve the intended visual quality, provide responsive image sources, reserve layout space, lazy-load noncritical media, and avoid shipping assets that are larger than the rendered context requires. Alternative text should describe meaningful images for accessibility rather than being used as a place to force keywords.
Owner: The front-end implementer, with visual approval from the designer.
Verification: Test representative pages on mobile and desktop with browser performance tools, inspect the network payload, review Core Web Vitals field data when available, and confirm that optimizations have not introduced visible artifacts or broken interactions.
JavaScript Delivery Makes Important Content Harder to Discover
Observable evidence: Service copy, navigation links, or portfolio descriptions only appear after client-side execution, depend on interaction to enter the document, or disappear when scripts fail. Search engines can render JavaScript, but rendering and indexing problems can still arise when essential content is not reliably available or links are not expressed in crawlable form.
Consequence: Important pages or text can be discovered later, interpreted incompletely, or become fragile when rendering fails. Heavy script execution can also make the page less responsive for prospective clients.
Correction: Prefer server-rendered or statically generated output for essential content when the framework supports it, keep internal navigation crawlable, and treat animation as enhancement rather than the only way core copy becomes available. The goal is resilient delivery, not removal of modern interaction design.
Owner: The developer responsible for the rendering architecture.
Verification: Compare source output with rendered output, inspect the page with scripts disabled or delayed, use search inspection tooling for important URLs, and confirm that navigation remains discoverable without relying on custom interaction handlers.
Local Visibility Is Ignored Even When the Designer Has a Genuine Local Market
Observable evidence: A freelancer with a real business location or clearly defined local client base omits accurate location context from the site and does not maintain consistent business information. The opposite error also occurs when a remote designer creates nominal city pages or location claims that are not supported by a genuine presence or useful local information.
Consequence: Legitimate local relevance may be unclear to prospective clients and search systems, while artificial location targeting can create thin or misleading pages. Working 100% remotely does not itself justify claiming local presence in every market a freelancer hopes to serve.
Correction: If the business is eligible for a Google Business Profile, keep it accurate and follow platform rules. On the website, describe the real base of operations and the areas genuinely served. Create a dedicated location page only for a genuine location where useful location-specific information exists; do not clone generic service copy across nearby markets.
Owner: The business owner, because location representations and profile eligibility are business facts rather than copywriting choices.
Verification: Check the published business details for consistency, review the live profile if one is used, and confirm that each location page provides distinct information that a person in that market could actually use.
Service Pages Are Too Thin to Support a Buying Decision
Observable evidence: A service page is little more than a capability list, visual montage, or contact button. It does not explain who the service is for, what is included, how the work is approached, what evidence supports the designer's fit, or what a prospective client should do next. A previously published internal editorial target used 800 to 1,200 words as a planning range, but that range is not a search ranking requirement and should not be treated as one.
Consequence: The page gives both prospects and search systems limited context about the service. It may attract branded visitors who already understand the designer, yet remain weak for commercial searches where the visitor needs enough information to compare providers.
Correction: Expand the page around buyer questions rather than around a target length. Explain scope boundaries, process, relevant case studies, common decision concerns, and the type of client or project the service fits. Where editorial depth naturally exceeds the old planning range, keep the useful information; where the answer is complete sooner, do not pad it.
Owner: The designer or strategist responsible for service positioning, with technical review for internal linking and metadata.
Verification: Read the page as a prospective client, check whether it answers the main comparison questions without requiring a call, review search queries and engagement data, and confirm that related portfolio work links back to the relevant service page.
Design Jargon Replaces the Language Prospective Clients Use
Observable evidence: Headings rely on specialist terminology while the business problem is hidden in body copy or omitted entirely. Terms used comfortably among designers may not match how a founder, marketing lead, or small business owner describes the same need.
Consequence: The page can communicate expertise to peers while making relevance less obvious to buyers. Search queries and page language become misaligned, and promising prospects may not immediately understand what outcome or service the designer is offering.
Correction: Start headings and key summaries with the client problem or service language, then introduce the technical design concept where it helps explain the solution. Use Search Console query data, sales-call notes, inquiry language, and client briefs as evidence for wording choices instead of guessing at terminology.
Owner: The person responsible for messaging, ideally with input from whoever handles sales conversations.
Verification: Compare page language with real inquiry language and relevant query data, then confirm that the revised copy remains accurate and does not oversimplify the design work.
Redesigns Change URLs Without a Migration Plan
Observable evidence: A redesign changes portfolio, service, or article paths while old URLs are removed, internal links still point to previous paths, or external backlinks resolve to missing pages. A migration may need a 301 redirect for a moved resource, while unresolved requests can surface as 404 responses.
Consequence: Users and crawlers can lose the path to established content, external links may stop resolving correctly, and search visibility can decline because the replacement relationship was not communicated clearly.
Correction: Inventory existing URLs before launch, map each moved page to the closest relevant replacement, keep unchanged URLs unchanged where practical, update internal links, and implement the appropriate 301 mapping. Do not redirect every removed page to the homepage when there is no meaningful replacement.
Owner: The person managing the redesign release, with development ownership for redirects and content ownership for deciding which old pages have true replacements.
Verification: Crawl the site before and after launch, test the redirect map, monitor indexing and search performance, and review reported 404 URLs so genuine migration errors can be separated from obsolete or malformed requests.
